[wxCode-users] RFC - Re: wxCode problems and wxWPM

[Francesco M. <f18...@ya...>]

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