Hi all, what about this? the mail is long but if you want just the "summary" you can read just the last lines ;)
Thanks! Francesco Francesco Montorsi ha scritto: > Matías Szeftel ha scritto: >> Every one on wxCode could try this if is no too much hassle and offer it >> as a download option. In the hope of having a nice users base. It would >> be nice to have a nice packaging system for our wxWidgets applications. >> I'll try to use it in the next wxARG release. > Great, thanks! > > This makes it possible for me to introduce a big topic which I already wanted > to > do :) > > Currently wxCode internals have some drawbacks: > > 1) administration is not as easy as it should be: approving new components > takes various time and the current internal structure of wxCode website is > not > very easy-to-update / straightforward. > > 2) browsing the component list is not as fast as possible: except for the > links at the top and at the bottom of the page (those to other categories of > components) the content is still generated on-the-fly. > Initially I thought to cache only the links (since generating that set of > links > is a _very_ slow operation) to allow the developer which uses the > > http://wxcode.sourceforge.net/edit.php > > page to immediately see his changes reflected on the component list page, > without the need of waiting that some cron job on SF regenerates that page. > > However, I now realize that the infos of the components are not updated so > often > and that the entire contents of the complist.php page could easily be > cached > and refreshed only, say, once per day. > > 3) component infos are not in CVS: before my restructuring of wxCode the > (very > few) info characterizing each components were kept in the Readme.txt file > which > any component should have placed in its root folder. > While this made impossible an automatic generation of nice web reports, it > was > more programmer-friendly than the current DB-driven solution because it > allowed > the developer to avoid to use the web interface at > http://wxcode.sourceforge.net/edit.php to modify and/or keep updated the > component infos. The file was kept in the source repository and thus when > e.g. > making a new release the programmer only had to modify the version number > there. > > I don't know how many of you use http://wxcode.sourceforge.net/edit.php but > I'd > guess (not sure however) that many components have outdated infos also > because > of the lazyness of the programmer to update the wxCode internal DB. > > 4) programmers do not keep up2date their components / upload sources to CVS. > > [ 5) if you think I'm missing something else, please say your opinion... ] > > > If we decide to solve problem #2, i.e. cache the components HTML description, > then the wxWPM project may help us to partially solve #1, #3 problems > providing > the following (big IMO) advantages: > > 1) the component infos would be stored in the CVS in an XML-like format, > i.e. > as a wxWidgets package descriptor (WXP). > A sample WXP file for my wxXml2 component is at: > > http://wxcode.svn.sourceforge.net/viewvc/wxcode/trunk/wxCode/components/wxxml2/build/wxxml2.wxp?view=markup > > having it in the CVS/SVN allows the developer to easily keep it updated. > > > 2) the component list HTML pages could be easily created using 'wxp' > command > line program (just look at http://wxwpm.sourceforge.net/packages.php - it > looks > familiar, isn't it ;) ?), and thus also cached and regenerated anytime > there's a > change. > > Also, updating the website to e.g. a new look would be extremehely easy: just > changing the "viewformat" used by the 'wxp' utility (while to change the look > of > the component list would currently require changing lots of PHP code). > > > 3) it would simplify the wxCode website structure, because the DB should > not > be necessary anymore: from that WXP file (which also contains MORE INFO on > the > component rather than those currently contained ), the 'wxp' command line > utility can generate the HTML description of the packages. Thus the wxCode > PHP > website should not query the DB anymore but rather use those cached HTML code > snippets. > > > 4) the maintainer of the component could create more easily the releases of > his component. With the info taken from the WXP the 'wxp' utility is able to > automatically create the .zip or .tar.gz excluding e.g. the object files, the > CVS/.svn folders from the archive, etc. > Those releases would automatically be directly usable as wxWidgets packages > from > the wxWPM Package Manager. > > > The drawbacks of switching to the use of WXP files rather than the current DB > solution: > > 1) administrators of wxCode should necessarily install 'wxp' utility to > update > the HTML descriptions and/or add new components > > 2) all the maintainers should keep the WXP file (and update it) in the repo > of > their components. > > > What do you think? Are they acceptable? > > > Looking forward to hear your opinion, > Francesco > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ wxCode-users mailing list wxCode-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxcode-users
