Re: [Zope-dev] Integrating mailman with Zope?
On Thu, 6 Dec 2001 08:33:41 - Adrian Hungate [EMAIL PROTECTED] wrote: I've been away and I am only just catching up with Zope-dev. I have been working on a ZCGI product for a long time, but I keep getting stuck when I try to port it to Windows (No pipes - No nothing in fact) :( I'm afraid my solution won't help there. I basically just rewrote the standard Python popen library (to pass the environment to the CGI script), and haven't tested it on Windows. I'll send you my code separately so you can see what I've done. BTW, the project page for EcoAccess is on SourceForge at http://sourceforge.net/projects/ecoaccess All of our code is in our CVS repository there (drop me an e-mail if you need help finding it). If you want to look at the code, drop me a line Sure, that would be great. Can you send me what you have? Thanks! Fred - Original Message - From: Fred Wilson Horch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 26, 2001 5:39 PM Subject: [Zope-dev] Integrating mailman with Zope? Hi everybody, After a hiatus on our project to integrate Mailman and Zope 2.3.x here at EcoAccess, we're about to tackle it again. Has anyone out there tried this already? Last we heard, Mailman was a standalone CGI program, and in order to make it work with Zope you had to run both Mailman and Zope behind another web server (such as Apache). What we're planning to do is write a CGI product for Zope 2.3.3 so that we can run CGI programs with ZServer under Zope, eliminating the need to set up and configure Apache or any other web server. If you've already written a CGI Zope product (i.e., a product that lets you run CGI programs from any Zope folder), please let me know! Otherwise, I'll continue the experiments. ;-) Best regards, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fully Zope-based Mailman Version
This is great! Finally somebody is working on integrating Mailman with Zope! Count me in -- we had a volunteer struggle with the Mailman code over the summer before giving up. Fred P.S. By the way, last week I added CGI 1.1 support to Zope 2.3.3. This allows us to run the existing Mailman code (version 2.0.7) as a CGI script without having to run another web server besides Zope / ZServer. If anyone is interested in this code, please let me know. Right now it is an external method that requires the PathHandler product. The basic idea is to parse the URL using PathHandler, which calls our external method. Our external method sets up the required environment variables (has to correct a few glitches introduced by Zope in the environment dictionary), forks and execs the CGI script with the cleaned up environment dictionary, parses the output the CGI script returns, cleans up its forked children, and returns the CGI script output to the browser. This is all working fine with Mailman 2.0.7, Python 1.5.2 and Zope 2.3.3. I've tested a few other CGI scripts. YMMV. Maybe Zope already supported CGI scripts, but I sure couldn't figure out how to make them work! -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZPL and GPL
Barry A. Warsaw writes: I think I'm accurately channeling Guido when I say that Python will never be GPL'd. AFAIK, there is no GPL code even in the standard Python distribution. Both of those states of affair are by conscious decision: regardless of what you think of the GPL (and I personally happen to believe it can be a good license for /some/ software, but not all) GPL'ing Python would be a very bad thing. Guido has always intended for people to do whatever they want with Python, including using it in everything from closed source, proprietary, big-$$$ software to completely free software. That's been a key to Python's success, IMO. I respectfully disagree about the last point. But it would be nice to hear what Guido thinks, and what Digital Creation thinks. Knowing that the copyright holders have made a conscious decision not to allow developers to obtain Python and Zope under the terms of the GPL in the belief that this allows people to do whatever they want with it does help us evaluate the long-term prospects for these systems in the marketplace. I would love to take this discussion to a different forum. Can someone post the name of the zope licensing list so I don't waste non-lawyers' time with an analysis of the correlation between licensing schemes and success of various open source projects (a subject we intellectual property attorneys find extremely fascinating!)? Some compelling case studies are Linux, gcc, apache, perl and ruby (see, in particular, Ruby's choice of licensing provision at http://www.ruby-lang.org/en/LICENSE.txt -- you can get ruby either under the GPL or under a home-grown Ruby license -- your choice). Python is a great language, but it's not the only game in town! It's very hard for me to see how offering developers the choice to obtain Python both under the GPL and under a non-free software license that permits proprietary extensions would harm Python's success. (But I'm just an attorney. ;-) I hope this discussion is interesting and useful. To people who have better things to think about: I apologize for taken up time with this, but I hope one day a discussion of the licensing uncertainties surrounding Python and Zope will no longer be necessary. Best regards, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZPL and GPL
the GPL and linked with Python. So if you feel that the GPL affords your code useful benefits and protections, you now have that option, whereas under Python 1.6, 2.0, or 2.1 you didn't. Yes, it could be (and was) worse! Here are my final thoughts (which admittedly seem to go against some other opinions expressed): 1) If we can convince Digital Creations to abandon the ZPL and at least license Python and Zope identically, then we're making progress. 2) Adopting a standard license already in wide use (instead of perpetuating a series of home-grown Python/Zope licenses) would be additional progress. 3) Nirvana will be achieved by joining with the true believers in GPL purity. ;-) Let me know if lawyers are welcome on the zope-licensing mailing list, if such a place exists. Peace and productive coding! Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZPL and GPL licensing issues
Dear Digital Creations, Thank you for providing Zope. Please consider releasing it under the GPL. As a non-profit organization that is recruiting and training volunteers to develop code for our web site that runs on Zope, the license uncertainty is wasting our time and may force us to abandon Zope as a core element of our technology platform. Zope takes advantage of a body of work and a community of people made possible by the pioneering efforts of the Free Software Foundation, source of the General Public License (GPL). Now that Python itself is being distributed under a GPL-compatible license, you could save everyone a lot of time and grief by clarifying your business model and the relationship you would like to have with your development community. Offering developers the choice to obtain Zope under the GPL would send a clear message that you value us. I would love to discuss the issues in detail with you or your legal counsel by e-mail in a public forum. Perhaps a zope-license mailing list would be useful to all concerned. Sincerely, Fred Wilson Horch, JD Boalt Hall School of Law, UC Berkeley '95 Development Editor, High Technology Law Journal '94 - '95 -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Professional Sites Using Zope??
On 16 May 2001, at 12:15, Jawad wrote: I am also interested to know Is there any professionally developed sites in Zope/Python. Please let me know the URL. Our non-profit's web site is developed in Zope/Python, using a combination of volunteers and paid contractors. The URL is http://ecoaccess.org/. Regards, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question about import code
Hi Shane, You wrote: Importing multiple objects simultaneously could result in a fair amount of confusion... Can you elaborate? When you import a folder, for example, it imports the folder and all objects in it. Why is it any different to import two unrelated objects? Would it be better to do this in two separate transactions? Or two subtransactions? But if you really think it's a good idea, if you used a list called return_oids instead, and appended to this list in the code above, you'd probably get what you're looking for. I tried this approach, too, and I get a ConflictError. (I can send the code and traceback if you're interested.) Note that for Zope 2.4 this code has changed a bit. Import is now done as a subtransaction rather than a transaction on the side. Thanks for the heads up. When you say subtransaction, a subtransaction of what? I'm familiar with subtransactions being atomic parts of a larger transaction. I'm not sure what this larger transaction would be in this case. If I start an import, does that start a transaction with each object's import being a subtransaction of the whole thing? (If that's the case, then I don't understand why importing several objects at once would be confusing.) Is there any documentation on how to export from and import to the ZODB? The code I'm wading through has a lot of extraneous stuff thrown in. I'd like to be able to just try exporting and importing objects from a simple Python script so I understand what's going on. Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Question about import code
Hi folks, I have hacked on the export code to allow you to export more than one object at a time. Now I'm trying to grok the import code. Can someone help me figure out what's going on? I have an export file in XML format that looks like this: ?xml version=1.0? ZopeData record id=5602 aka=FeI= [ first record's data here... ] /record record id=5603 aka=FeM= [ second record's data here... ] /record /ZopeData If you export a folderish object, you'll see basically the same export format. (When you export a folder, you get all of the objects rooted in that folder.) The difference is that these two records are not related -- they are simply both contained in the same folder. The problem that happens on import is a KeyError on line 194 of this bit of code: lines 192-197 of lib/python/ZODB/ExportImport.py ooid=h[:8] if oids: oid=oids[ooid] if type(oid) is TupleType: oid=oid[0] else: oids[ooid]=return_oid=oid=new_oid() If I change this code to ooid=h[:8] if oids and oids.has_key(ooid): oid=oids[ooid] if type(oid) is TupleType: oid=oid[0] else: oids[ooid]=return_oid=oid=new_oid() then the import appears to succeed, but only the final object in the file is actually imported. I have to say that some comments would be nice in lib/python/ZODB/ExportImport.py Also, are both of these files used? lib/python/ExportImportXML.py lib/python/OFS/XMLExportImport.py Plus, I am having a hard time finding the right documentation for working directly with the ZODB to see what's going on. Can someone help point me in the right direction? Here's what I'm trying to accomplish: 1. Allow multiple objects to be exported at once (this is working) 2. Allow multiple objects to be imported at once (this is not) 3. Allow imports to overwrite existing objects (haven't tried this yet) Thanks in advance for any assistance. Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Steve, You wrote: Fred We currently have two serialization interfaces in Zope: Fred 1) the FTP interface, and 2) the XML export interface. Hmm.. maybe I'm misuderstanding... which would/could you use for version control? The XML interface. It still seems to me that a blend of these could be developed that would work in all cases. An object could have a human readable part/aspect and 'the rest' could be captured as an xml bloblet. The 'human editable' part could just be what you get on the FTP interface (as you say), and the rest could be saved/restored to a 'auxiliary' file that would track other aspects of the object. Since objects could implement their own serialization, they could decide what aspects belonged in which part. Otherwise I can't help feeling that we'd have problems with duplicated versions, some xml/zexp, some human-readable that would inevitably stomp on eachother in any version control scenario. If all this could be worked in to the existing FTP/export/import system... there would be a minimum impact on existing interfaces. That was my original sentiment, too. But Chris McDonough's proposal (http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesystem) seems to allow developers to ignore any 'auxiliary' information that is not easy to serialize. I've come around to the viewpoint that the FTP interface (which in my opinion is what Chris' proposal is replacing) could just be used for editing objects one at a time. You can afford not to represent some information in this situation. It is just like through the web editing, but allows you to use emacs or Microsoft Word (or whatever client side tools you have that work with files on your filesystem). Fred FWIW, I'm working on tweaking the XML export/import code to Fred serialize object hierarchies as directories and files, Fred rather than exporting a single file. Cool.. this sounds like a promising approach. I'd be interested in testing this.. The reason I'm working on this is that I think the XML serialization is what developers should use for source control / configuration management. There are really only two major problems with the existing XML serialization functionality that prevent us from using it with CVS: 1) everything is serialized to a single monolithic XML export file, and 2) you cannot update existing objects from an XML export file Hopefully I will have some code soon based on the existing export code that allows you to export any part of the object tree as a hierarchy of directories and files in Python Pickle Markup Language (ppml - the format used by the existing XML export), and import ppml files to update existing objects in the ZODB. By the way -- is it me, or is the current Import/Export interface broken? I tried to select multiple objects to export, but I can only get the first one to actually be exported. Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Steve Spicklemire wrote: I posted this to the Wiki... but it's not "in-your-face" like email, so I never know if anyone reads it. Thanks for sending this to e-mail. (I never read the Wikis -- I mean to, but never find the time.) I'm looking at all this from the perspective of someone who is using the current xml/zexp code to manage objects in CVS today Can you tell me how you do that? Our big problem is that we can't import over existing objects. Are we doing something wrong? Here's our set up: We have developers all over the world that can check code in and out of SourceForge. We'd like our developers to be able to work on our site using their own local instances of Zope, export everything from their Zope ODB to their local filesystem, then use CVS to check in all the changes they've made to SourceForge. Then to keep in synch, everyone else can update their local copies of the source tree, and import the updates into their local instances of Zope. The problem: imports raise all sorts of conflict errors -- we basically have to delete everything before importing it. It seems to me that the current import/export mechanism is actually pretty close to what we need for serialization. I agree. We also have the hooks for a file system like representation already built in with the FTP interface. So I think an evolution rather than a revolution it called for. I want to comment on the rest of your message, but will have to do that later in the week. Thanks for sharing your ideas. Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Wanted to follow up on Steve's points. He wrote in part: [...] It seems to me that the current import/export mechanism is actually pretty close to what we need for serialization.[...] A) All objects are faithfully encoded and saved on the filesystem in a text format that any configuration management system can use and track. [...] B) Whole object hierarchies can be saved in a simple file, moved to any other zope instance (via checkin/checkout) and instantiated. [...] C) It's possible (through a hack[1]) to make simple objects 'diff'able so that all the metadata that's in the current xml export rep doesn't get in the way too much. [...] There are also a few not-so-nice properties: D) The current xml representation use by xml import/export is morally binary, in the sense that you can't easily edit/manage it with ordinary editors etc. E) There is no simple way to separate the contents of a containerish object from the container. [...] Imagine the following: A 'serialization' interface is invented that objects could implement that preserve A-C, and, optionally, fix D-E. If no such interface is found, the current export method is invoked. [...] I don't know if we need just one serialization interface that tries to solve all five issues. We currently have two serialization interfaces in Zope: 1) the FTP interface, and 2) the XML export interface. Seems to me that the FTP interface could be generalized as the "lossy" serialization interface that is "morally human readable" and the XML export interface could be tweaked a bit as "lossless" but "morally binary". The FTP interface would be used when you want a representation that can be edited by hand. It solves C, D and E, but not A and B. The XML interface would be used when you want a representation that can be manipulated programmatically. It solves A and B, but not C, D and E. FWIW, I'm working on tweaking the XML export/import code to serialize object hierarchies as directories and files, rather than exporting a single file. Fred P.S. The link Karl sent (http://www.thetwowayweb.com/theXmlFiles) is interesting. -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
ach would be different than FSDump and ZCVSMixin, right? As far as I understand it, FSDump just goes one way (ZODB - filesystem) and only for certain types of objects. I don't understand what ZCVSMixin does (will need to spend some time looking at it -- unlike FSDump, ZCVSMixin is not obvious from the documentation and a quick review). Thanks for helping with this project! Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
"Dan L. Pierson" wrote in part: I think lossless serialization should be an explicit goal. What is lossless vs. non-lossless? If the filesystem representation dumps evrything required to recreate a working copy of the catalog after a (perhaps lengthy) computation but doesn't actually dump the full current contents is that a lossless representation? Yes, in my book (as long as original and recreated copies of the catalog are functionally identical). I'm using lossless in the sense it is used in the compression field. If you can recreate the same objects from the representation (even if it requires several computational steps) then the representation is "lossless". A "lossy" representation would mean that you lose some piece of information that is essential to getting back to the original state of the object database. For images, JPEG is a lossy compression scheme, which means it is one way. If you convert a TIFF to JPEG, then you can't go back to the exact same TIFF. By contrast, PNG is lossless. You can convert from TIFF to PNG and back to TIFF and get the exact same TIFF. My concern is that if the plain text serialized format is lossy, it will be one way only. That is not good for us. To preserve the round trip ability, we need a lossless representation. The whole point for us is to get full control of our objects through CVS. And grep and emacs, etc. Yes. CVS is the principal driver for us, but grep and emacs are important too. If all you need is CVS, a "morally binary" XML representation can do. Zope already provides one, though it is not ideal for CVS. If you want to be able to use other file system based tools (a.k.a. normal development tools) then you need a representation much closer normal text. It's almost obvious what this should be for folders, DTML, ZSQL, PythonScripts, etc. It's much less obvious what this should be for ZCatalogs, Racks (yeah DC probably doesn't care but I do), ZClasses, etc. Good points. I'm eager to hear from anyone else with a perspective on this before I start coding something up. Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Chris McDonough wrote: Fred Horch wrote: My major question is I don't understand the design decision to allow lossy representation. [...] I think lossless serialization should be an explicit goal. If a developer doesn't provide specific object serialization methods, then a default method (perhaps XML) should be invoked that is lossless even if hard to work with. I think the proposal says something like this. The proposal states in part: If this API is not implemented by the developer, the result is undefined (XML pickle representation if allowed by the object on a per-object basis?). I guess I'm voting to rewrite this sentence: If this API is not implemented by the developer, the result is a default serialized representation (perhaps XML pickle) on a per-object basis. The whole point for us is to get full control of our objects through CVS. That's one use, which is important to you. Another is to use Emacs or Dreamweaver on a representation of, for example, DTML methods on a filesystem, which is important to other folks. The point of having potentially "lossy" representation of objects is to make it easier to work with them in these kinds of tools. Nobody wants to edit XML, AFAICT. I see. I agree with the goal to have a representation that is easy to work with in emacs. Would it be possible to have a "lossless" representation that is also easy to work with? The current XML export format is "lossless" but hard to work with. "Potentially lossy" also doesn't mean "leaky". It just means that folks who expose their objects to this sort of serialization can choose their own format, and if it represents the object adequately for their own use in both directions, it's good enough. Maybe the issue is semantics. I think "potentially lossy" == "potentially leaky". Even a small leak would cause problems for us. Maybe it wouldn't cause problems for others. But it sure seems like it would be possible to create a solution that works for everyone. Namely, a lossless representation that is easy to work with. I completely agree with the point that we want to be able to work with representations of objects using tools like emacs and dreamweaver. In fact, we'd like to use emacs as our front end to CVS. The ideal situation would be to edit Zope objects in emacs, publish them to a Zope object database, test them (perhaps using a separate web browser like Netscape or Internet Explorer), and then once everything is working, commit the objects to a CVS repository (using emacs or from the command line). If you want a lossless "morally binary" representation, it's probably best to use XML export, which is great for your purposes, because it already exists! ;-) I've heard it said that all progress is due to the unreasonable man. So to do my part for progress, what I want is a lossless "morally plain text" representation. ;-) If the existing XML export really was great for our purposes, I'd be done! The problem is that everything comes out in one big monolithic file. That's not good for project management using CVS. (At least, as far as I can tell.) I think there is the potential for a really good solution that solves our need to manage our project via CVS, and to solve the greater need to enhance the Zope management interface to support tools that work with filesystem objects. I am about to jump into this project next week. I do want to stay in touch with anyone who is working on similar projects, so please keep in touch! I will post reports as I make progress in case anyone is interested. Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Object serialization (was Re: [Zope-dev] FTP interface being worked on?)
I hope folks don't mind if I resume the object serialization thread on
the mailing list.
Chris McDonough wrote:
I wonder if yet another interface is really required. If you think
about it, isn't the FTP interface basically a file system serialization
format?
Yes! [...] It's probably not even fair to call this kind of
serialization "filesystem serialization" because it's the sort of
representation of objects that can be used by FTP, WebDAV, etc. It's just a
human-readable representation of Zope objects that fits into a
filesystem-like model that attempts to preserve most object information
(although there's no guarantee that it won't be lossy).
The "no guarantee" lossy part bothers me.
For our purposes, we'd like to see lossless serialization that provides
full control over objects through FTP, WebDAV, etc.
Lossy serialization will cause problems for round tripping objects, i.e.
getting them out of the object database, updating them, then putting
them back in.
One of our goals is to be able to use CVS to track our updates and
distribute our object database. We definitely do not want to be losing
information through serialization.
I understand your point about having each object's serialization "look
like" that kind of object, but isn't there also some value in the
consistency of XML representing every kind of object? For automated
tools, it seems like an XML representation is a great idea, and one that
could be exploited with a good client-side tool that understands the
Zope ODB DTD.
Yes, and this is great for XML export. But I see filesystem serialization
and XML export as different things.
No disagreement here. I wouldn't want to have to deal with the XML
representation when I'm using an FTP or WebDAV client.
Zope already has a little-known XML
format for representing python objects ("ppml", Python Pickle Markup
Language), which is the format which XML exports are done in. But when
developers work with filesystem reps of objects, I'd hate for them to have
to work with it.
Good point. So the XML format stays monothilic (i.e an XML export of
the root object creates one big file, not a directory full of
sub-directories and files representing objects) and when you want to
deal with files and directories you don't get the XML format, you get
something else.
That means that each object needs to support two serialization formats:
XML and the "filesystem serialization" format.
So I basically see three interfaces as necessary and sufficient:
1) XHTML - gets you started, can manage things with a browser
2) FTP - serialization to and from a filesystem
3) XML - the advanced management interface, easy to automate
To elaborate, first, the existing FTP serialization format could be
enhanced to be this "filesystem serialization" format.
Second, the XML serialization format could be the basis for some
sophisticated client side management tools based on XML-RPC. Unlike the
existing HTML (or XHTML) client side management interface, an XML
management interface could leverage XML libraries for parsing serialized
object data, and for communicating with Zope via XML-RPC.
Wow! Looks like you're planning ahead. I probably won't be available for a
little while (I'm off this week), but hopefully I can get that proposal
cleaned up and on the fishbowl and we can resume this discussion in that
Wiki.
Okay, I'll try to deal with the Wiki. But I have to admit that I find
the Wiki interface painful. Is it okay to keep using the mailing list
for discussions like this? I assume the keeper of the Wiki can copy and
paste useful bits into the Wiki as the mood strikes them.
Fred
--
Fred Wilson Horch mailto:[EMAIL PROTECTED]
Executive Director, EcoAccess http://ecoaccess.org/
P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi again, I'm commenting by e-mail because the Wiki interface is too horrible for me to face on a Saturday night when I should be doing other things. ;-) Chris McDonough wrote: I've put the proposal up at http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst em. Let me know what you think! This is a great start. My major question is I don't understand the design decision to allow lossy representation. Seems to me this is a recipe for disaster. You aren't working with Microsoft on this one, are you? ;-) Will there be some undocumented API call that only Zope employees know about to get the serialized lossless representation? ;-) The proposal states in part: "Lossless" general serialization is not an explicit goal. If a developer wishes to make his or her object serializable to a directory structure, he or she will need to implement methods of an API on the object instance which allow it to be represented adequately enough to be reconstructable into its original Python representation when it's "imported". If this API is not implemented by the developer, the result is undefined I think lossless serialization should be an explicit goal. If a developer doesn't provide specific object serialization methods, then a default method (perhaps XML) should be invoked that is lossless even if hard to work with. The worst thing you can do is make some things hidden in the ZODB and only available through a certain interface. The whole point for us is to get full control of our objects through CVS. I need to get started on something for our project so we can manage our objects via CVS by the beginning of May. I have taken a look at http://www.zope.org/Members/tseaver/FSDump and http://www.zope.org/Members/sspickle/ZCVSMixin. Can anyone tell me where my effort would best be spent? Would it be best for me to start with FSDump or ZCVSMixin and corrupt them to serve my evil plans, or should I start from scratch based on the object serialization discussion we've been having (but with the explicit goal of lossless serialization, unlike Chris' proposal)? To understand what I want to do, you can read my two project proposals at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/ftp_access/?cvsroot=ecoaccess http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/xml_rpc/?cvsroot=ecoaccess Thanks in advance for any advice! Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Chris, Thanks for the pointers to the work others have done. You wrote in part: Tres Seaver has done some work on this with his FSDump product (http://www.zope.org/Members/tseaver/FSDump), although it only goes "one way" at the moment, and Steve Spicklemire has gone a slightly different route with his ZCVSMixin product (http://www.zope.org/Members/sspickle/ZCVSMixin/). I will take a look at these. I see they are both Zope Products. I had not planned to write a Product, but maybe I should reconsider. For the FTP interface, I had planned to hack on the Zope internals directly. And for the XML-RPC interface, I had planned to write a separate client that could leverage the XML-RPC support already built into Zope. I have a proposal up on the Digital Creations intranet which makes the proposal to leave serialization format up to each object, and gives some info about possible implementation strategies. Get that proposal in the Fishbowl! ;-) I wonder if yet another interface is really required. If you think about it, isn't the FTP interface basically a file system serialization format? All objects already support the FTP interface -- if we improve it, then conceivably we can use standard FTP mirroring tools for filesystem export and import. Another serialized format that all Zope objects support is the XML interface, which exposes all the objects' guts. With XML-RPC I envisioned being able to improve on the FTP interface by adding things like md5 checksums to determine if the local and remote objects are in synch. I haven't looked too deeply, but presumably via XML you could support all of the management functionality that is currently provided by the HTML management interface. So you could build a client with a rich feature set for managing Zope objects. I understand your point about having each object's serialization "look like" that kind of object, but isn't there also some value in the consistency of XML representing every kind of object? For automated tools, it seems like an XML representation is a great idea, and one that could be exploited with a good client-side tool that understands the Zope ODB DTD. So I basically see three interfaces as necessary and sufficient: 1) XHTML - gets you started, can manage things with a browser 2) FTP - serialization to and from a filesystem 3) XML - the advanced management interface, easy to automate I don't know much about WebDAV -- since we're a volunteer organization, we are using free software where possible and I haven't seen much free software that supports WebDAV. cadaver seems to work fine with Zope. But I can easily see the combination of FTP + CVS providing us everything we need. So in some ways WebDAV seems like an extra that will be nice if and when there are clients that support it. I hope this email serves as a sort of overview about what we want to do about the problem at DC... it'd be great to be able to conserve resources and work on the same problem together. Absolutely! We liked your Fishbowl process so much we are basing our own development process on it. (For details of our process, check out http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/docs/tech-process.txt?rev=1.2content-type=text/x-cvsweb-markupcvsroot=ecoaccess ) -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
You may also find our documentation process interesting: http://www.zope.org/DocProjects/intro Yes, very interesting! But I'm sorry to see that the Developer's Guide is only in the planning stages. Here is some info that should go into it (from our Zope notes at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/docs/notes-zope.txt?rev=1.8content-type=text/x-cvsweb-markupcvsroot=ecoaccess): This section explains the directory structure you'll find when you unpack the Zope 2.3.1b1 source tar file. Root directory: Extensions/ code for External Methods go in this directory ZServer/ python code for ZServer and medusa (see the README.txt) doc/ documentation (especially INSTALL.txt) import/ used by the running Zope process to import objects into the ZODB inst/installation scripts lib/ python library (most of Zope's code is under here) pcgi/C and python code for PCGI (see the README) utilities/ random utilities (see the README.txt) var/ contains the FileStorage for the ZODB (Data.fs) and various other files (logs, pids, etc.) LICENSE.txt Zope Public License (ZPL) Version 1.0 README.txt general information about the Zope source release w_pcgi.pyscripts for setting up Zope with PCGI wo_pcgi.py without PCGI z2.pythe start script for Zope zpasswd.py create or change the Zope emergency account and password lib: Components python extension modules written in C - BTree, ExtensionClass, cPickle, zlib python everything else lib/python: Most of the Zope code is in here. -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FTP interface being worked on?
Hi folks, Is anyone working on the FTP support in Zope? For our project, we'd like to improve the FTP interface to Zope. I noticed that ZServer/README.txt in Zope 2.3.1b1 states Properties and FTP: The next step The next phase of FTP support will allow you to edit properties of all Zope objects. Probably properties will be exposed via special files which will contain an XML representation of the object's properties. You could then download the file, edit the XML and upload it to change the object's properties. We do not currently have a target date for FTP property support. I have a proposal written up, if anyone is interested in providing feedback to me before I start work on it. Along these lines, I also have a proposal to add an export / import feature that would dump objects in the ZODB to separate files in a directory tree. (Currently the XML export seems to create one big XML file.) The goal is to allow objects to be managed as flat files so you can edit them more easily and use CVS to track revisions. Also, it sure is confusing to try to figure out where you accept patches. Is the Collector still the best place to send them? Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Chris, You wrote in part: The "export as files" paradigm is something we'd really like to see soon in Zope. [...] I'd be interested in seeing your proposal too. Great to hear we're thinking alike. My proposals are available on our SourceForge site (sorry for the long URL -- I can send the proposals as an attachment if you'd prefer): FTP proposal http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/ftp_access/ftp_access_prop.txt?rev=1.2content-type=text/x-cvsweb-markupcvsroot=ecoaccess XML-RPC proposal (export as files) http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/xml_rpc/xml_rpc_prop.txt?rev=1.1content-type=text/x-cvsweb-markupcvsroot=ecoaccess The best place for these sorts of things are at http://dev.zope.org (the "fishbowl")... Okay, I'll take a look and submit my proposals through the Fishbowl process. Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
