The recent IDE thread has sort of got me thinking about my ideal vision of what Zope could do for and be to developers in the future, so perhaps my quirky visions here seem a bit ambitious, so take what I'm saying with a grain of salt (or a Tablespoon if you prefer)... So perhaps this message's subject might be best written as: Sean's Crazy Zope Wishlist... here are some random thoughts re: IDE for Zope... this message is long, so here is a summary: 1. create generalized toolkit/class library for desktop access to Zope; use wxPython... Work should be used for basis for IDE and a whole new generation of cross-platform desktop applications using Zope as a middleware core, expanding what Zope is used for, and the market opportunities associated with it for developers and vendors... 2. IDE should have ability to checkin/out stuff from server Products dir via FTP, as well as ODB; code should be synced from IDE/workstation to CVS, and also to Zope server for testing snapshots. 3. IDE should allow for unit testing of python classes using local python installation, and also facilitate debugging using python on server after a sync of code. 4. I'm not sure I would pay for an IDE versus using traditional tools, but I WOULD PAY FOR CASE TOOL INTEGRATION. I want forward/reverse engineering from UML; this would require the ability to have the CASE tool plugin cooperate with changes/evolution in Zope and any "standard" IDE, which means there is a sale-plus-subscription business model for this (for DC or another vendor to sell to ISVs?). Do this, and watch to "Enterprise Java" folks be converted - they really want to code in python, they just don't know it yet. ;) Anyways, if you aren't already bored to tears, read on... ------ Zope, via XML-RPC, could be a very good platform for creating an extensible toolkit for desktop access to Zope, wrapping XML-RPC calls to Zope machinery to do certain tasks. Such an abstract toolkit might provide a decent foundation for an IDE, but would also serve the purpose of allowing folks to write "desktop" (really: client/server) programs that interface with the Zope/ODB rather transparently by using the some prebuilt toolkit classes and basic-auth-wrapped python XML-RPC library. I could imagine having prebuilt library functions for Zope access (a desktop application that has a concept of a user-login and session, a URL, etc), admin (pack db, restart, backup/export object hierarchies to a local file), development (ftp checkin/checkout of code from Products directory on server, source/property editing of TTW objects), and general use (bound data controls - widgets like text boxes that are bound to a particular class definition, and represent members of instances of those classes, for example a widget has an associated get and set method within a class that it gets its text from and sets upon changes). Perhaps I'm dreaming here, but I really want to extend what I am doing in Zope in the future into cross-platform desktop development efforts. The rationale for desktop apps to be built with Zope is exists because: 1 - Data Entry: TTW editing is not always ideal; if I was building a content-system, for example, like a newspaper library system, Zope is an ideal platform for an asset-management system/content repository. But that task also involves a lot of editing, and the librarian will want to have hot-keys to modify content and navigate an entry-screen, it would make sense to make this a desktop app, as that kind of flexibility is not afforded by a browser and html forms. 2 - Current Desktop Client/Server apps are stale: Isn't the idea of ODB integration with desktop apps more exciting than standard 2-tier RDB apps? Wouldn't middleware based on lightweight, commodity technologies (http, xml-rpc, open source server software) like Zope make sense for the new "web services" paradigm? 3 - Zope has potential as an enterprise data-center mainstay, not just as a web-only application. This expands the market for Zope and vendors working with Zope, as well as expands the Zope community. 4 - Commodity internet technologies, especially with open-source cores, provide what might just be the core for the next generation of enterprise applications (both web-based and desktop c/s), especially in heterogeneous content environments (like publishing/media companies using something like this for the database core for print and online production systems). 5 - There is a market justification for vendors to sell more integration services to 2 market vectors (enterprise and web development), in both content-management and other verticals for which Zope might excel as a good development platform for a back end. In the newspaper editorial and asset-management systems business (I used to work for a vendor in this industry), for example, there is a great deal of talk about convergence and formatting-neutral content storage databases at the center of web and desktop apps; a lot of app & services sales within these markets are 6 to 7 figure sales to media companies, so there is opportunity, not in just this industry, but other content-heavy industries (medical, legal, etc) as well - for the same types of "integrated" solutions with a single commidity-web-based core, with desktop and web apps surrounding it. I'm currently doing a bit of playing around with wxPython, which reminds me a lot of my days programming with the Borland OWL class libraries, so I might be partial to such a solution using wxPython instead of tkinter (tcl interpreter - blech! motif-style widgets - yuck!). An IDE built with a decent (modern) widget set / UI class library, with extended toolkit functions, like data-bound controls, might make for an interesting user-extensible means of creating custom-tweaked IDEs, not to mention other desktop software that accesses Zope... I guess what I am saying is that we might as well have a toolkit for building desktop apps and kill two birds with one stone here if there ends up being any sort of IDE project. I also think that choosing to use a modern cross-platform desktop class library like wxWindows with wxPython might be a better choice than mozilla/XPCOM or tkinter... In addition to remote object/method calls, ability to sync local code done in the IDE with both a CVS server (whenever), and with the Zope server (on production/snapshot releases) via FTP would be good. The IDE should allow unit-testing and debugging using a python shell and a local python. The IDE should also automate the ability to telnet to the Zope server to do integration testing and verification using the python on the Zope server. I do this now with Idle on the Zope server via a remote X-Session (not entirely graceful, but it works). In addition to an IDE, I want to be able to have some good guidelines and documentation for standardized UML in Zope, so that when I share designs with colleagues, I don't have to use a ridiculous amount of my own flavor of stereotypes, just because I don't know any better. Once I have that, I want CASE->CODE->CASE tools with an existing tool (even if it is a Visio extension hacked with VBscript), but perhaps I am pushing my luck there. I just think that provided the ability to use standard editing tools, I would feel good to have the ability to do forward/reverse engineering from UML models. Such a tool might get some Java developers to jump ship. I might not pay for an IDE, but I WOULD PAY $$$ for a plugin that does forward/reverse engineering with an existing CASE tools (ObjectDomain, Rational Rose, Visio2k, etc). These are high-end tools that would likely only be used by a smaller group of folks than Zope's general audience, which, I assume makes this more ideal for a standard commercial software paradigm. Such a product would need to be able to change with changes/evolution in Zope, which means that a buy-once, buy a support contract for free updates would be a good model for anyone creating such a tool. Also, you keep the barrier to entry low for development in open-source projects built on Zope because you can always have folks without these tools submit patches, participate in development, and view a PDF or JPG of the UML diagrams if they so please... Sean ========================= Sean Upton Senior Programmer/Analyst SignOnSanDiego.com The San Diego Union-Tribune 619.718.5241 sean.upton@uniontrib.com =========================