Alex,
Thanks for your answer!
Quote:
However, that can force several hurdles when upgrading (if a new GT module is no longer backwards compatible for instance). We are currently looking at ways to improve this.
Yes, I supposed something like that.
Quote:
I'm not sure the structure you mention is appropriate though.
What structure would you imagine?
Quote:
Typically the only time you want to have a common library is if you are running multiple applications under the same persistent environment
Moving the GT libraries (at least for the newly released GT apps) to a common place, would help
- as you say, when running multiple applications under the same persistent environment
- reusing the different GT lib versions for custom developments
I'm basically interested in the second point. By this time, I completely dismissed CGI.pm usage from my custom website development and now I mainly relying on the GT library (it remains custom development, at least until I can not completely upgrade to LSQL). My website has a lot custom changes, and until LSQL misses a lot of them, I can not upgrade to LSQL.
It seems, later I will have to base my development to a slightly (highly?) modified LSQL version (because some features I need, can not be solved with plugins).
The final target is, to create a common application environment, which can be a common base for all of my services. Something between an Application framework and a Content Management System. That would mean: module & plugin based development and simplified content management.
So in result I will need to control more applications using GT lib placed to a common place.
IMHO, there could be an easy solution for new GT applications, to allow the user to change the GT lib path in setup.cgi.
This way it could be taken out from below the admin path.
Current GT lib install path is:
/cgi-bin/glinks/admin/ I would like to have the option to change this path, and install the GT lib under the following dir:
/cgi-bin/modules/ Would be fine to have the commonly used libraries moved out from the application directory itself, so could the libs be reused by several applications.
Another important thing: GT should let us know which GT lib version is used in which GT application, so we could know which is newer and which is older lib. I'm sure the GT staff already have internal version numbers for each GT lib, which was released with a GT app.
Version numbering the GT libs, would help the custom developers to keep a fine ordered collection of GT lib versions, which could make easier the development, providing backward compatibility when needed.
Also a 'GT_latest' dir could contain an up-to-date GT lib.
Might be a good idea to share with us, how do you plan to do the common GT library structure.
Just an idea: discussing the features you are planning on the forum, might generate some interesting ideas which may be helpful in your developments.
Alex,
nowadays it's hard to get in touch with you or other GT developers on the forum. Following suggestion is related this:
Announcing "development discussion day" regularly (monthly or quarterly, just 1 day?), when developers are doing just support work on the forum, answering about plans, features, accepting feature requests, etc... This would help to keep interest of the GT users on the forum, who rarely, but at least regularly would be able to get answers for all kind of their questions... Opinion?
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...