zope higher abstraction installation
hi there, on the survey on digicool i added some ideas to make the first step into zope easier. i'd like to hear your ideas about that and if any of that is already acomplished somewhere. * a roundtrip visual-RAD-database form/reports environment (visual to source and back) (better than MS-Access and probably with import of forms/reports form theKompany-REKALL and MS Access or other forms/reports designers :-) * out of the box multi language and database support * a closed zope installation option. means zope does not use local python or so. i had heaps of trouble with different versions of python, python-database modules and db-connector products (i rather have two pythons on disc than troubles with zope after updating my suse distro) still not solved after 3 months :-(. actually this stopped development of a product on zope. * faster implementation of patches (there is one problem with dtml-in orphans trouble that got a patch about 6 months ago and is still not solved in new zope versions) * a setup process, where the newbee-user can select what products should be pre installed. (e.g. according to usage questions like news-discussion -> squishdot, db-mysql -> MySQLdb+formulator db-pgsql -> PgSQLdb+ZDatabaseTool+QueryWizard(hopefully to be released by easyleading), Content-management -> CMF, XML, Templates -> ZPT, PIM -> iuveno-projector+others, eks -> KDESoHoServer-Components, multi-language-mysql -> MySQLdb+ZBabel, documentation -> local-zope-book, faq -> local-faq) -- this would show the capabilities of zope right away to the newbee. i remember how it took me weeks to figure out what zope can do. -- this also would move some zope companies into focus to the newbee that might want to spend money and outsource development. -- zope would grow into a plug-and-play-intranet/internet problem solver application hope for opinions olaf -- soli-con Engineering Zanger Dipl.-Ing. (FH) Olaf Marc Zanger Lorrainestrasse 23 3013 Bern / Switzerland Fon: +41-31-332 9782 Mob: +41-76-572 9782 mailto:info@soli-con.com mailto:olaf.zanger@soli-con.com http://www.soli-con.com
On Thursday 31 May 2001 02:57, Olaf Zanger wrote:
hi there,
hi olaf, i just finished reading your proposal for eks. very interesting, i've been thinking about things along these lines. it basically about pushing the envelope of 'web services' and zope. very cool, and powerful. bringing distributed objects to the desktop. you should really check out the python-dcop bindings and the kxmlrpcd, i've used them to script my desktop (kde2.1.1). there are no plans for kde2 python bindings that i know of (although phil thompson (pyqt/kde) says it just a matter of cookie cutting (paraphrase)). also you might want to outline the capabilities of particular applications that your interested in integrating in your paper. my biggest problem when considering this concept is that many of these applications are configured per user, which doesn't lend itself to a multiuser integrated system. still, tis a very interesting idea. cheers kapil
On Thu, 31 May 2001, Olaf Zanger wrote:
* a setup process, where the newbee-user can select what products should be pre installed.
This one is very good IMHO. But there will be two main issues there: - eventually some licensing problems. - actually no Zope package type. The fact that Zope hasn't got a preferred package type means that product installation is hard to do automatically: - you have to determine the true file type (.py, .zexp, .tgz, .tar.gz, .tar, etc...) - you have to take appropriate action depending on the previously detected type, which may be: tar + gzipped file: gunzip it. see if it installs in lib/python/Products or in Products or anywhere else. install it according to this. restart Zope and of course the procedure is different for each product and this must be done manually. So I really think we should create together a dedicated Zope package type ala .rpm ou .deb to distribute products and allow an automated installation. BTW I don't know if Distutils may fit in its current version, but I suppose it can do it just fine ! This package type would have to contain at least: The license: GPL, BSD, ZPL, Python, MPL, LGPL, etc... The author name and email The preferred URL The preferred installation directory: INSTANCE would mean $INSTANCE_HOME ZOPECORE would mean install from $ZOPEHOME Other informations as we may need (dependencies for example). Finally the "tarball": So with INSTANCE the tarball should contain: Products/MyProduct/... or: import/somefile ... but if INSTANCE is used and $INSTANCE_HOME doesn't exist then use ZOPECORE instead. and with ZOPECORE it may contain: lib/python/TAL/somefile or: Extensions/anotherfile ... So this will allow an easy detection of the destination directory, and allow an easy online installation with an Installation menu in the Control_Panel (and why not a ZShell "install" command ;-) Your thoughts ? bye, Jerome Alet
There is actually a proposal to canonize the disk-based Product specification at http://dev.zope.org/Wikis/DevSite/Proposals/FinishedProductGuidelines . It would be useful to have some of these comments there. Jerome Alet wrote:
On Thu, 31 May 2001, Olaf Zanger wrote:
* a setup process, where the newbee-user can select what products should be pre installed.
This one is very good IMHO.
But there will be two main issues there:
- eventually some licensing problems. - actually no Zope package type.
participants (4)
-
Chris McDonough -
ender -
Jerome Alet -
Olaf Zanger