Re: [Zope-dev] Zope3 on Google AppEngine
perhaps too late to help with the sprints, but i got zope3 running on app engine last week http://zope3.appspot.com and http://zope3.appspot.com/tests, and blogged about to http://blog.kapilt.com most of zope.app isn't useable due to persistence or containment and security proxies, but page templates and the publisher work. some fairly minor but pervasive changes (removing some deprecations/bbb code) were needed, and to have space (1000 file limit) to actually develop an application requires stripping the eggs of text and tests. i ended up using the publisher support in zope.publisher (3.5.1+) instead of ore.wsgiapp or lovely.nozodb as it presents a much more minimal dependency set. i'd like to see if i can get some form machinery going underneat the 1000 file limit, and publish a starter tarball for folks interested. i'm uncertain long term what's viable, as their were a number of changes needed, and how best to maintain them. if their suitable for upstream into the zope repository, or just done again for separate releases as gae variant of z3. cheers, kapil On 5/22/08, Jodok Batlogg [EMAIL PROTECTED] wrote: Hi, Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in stealth mode. We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note ([EMAIL PROTECTED], batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us. jodok -- Lovely Systems, Partner phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria _ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Component registry simplification leftovers
i was setting up a z3 app with a pau utility, and noticed some strange behavior, which tracked down to, the PluggableAuthentication's getPrincipal method, source below. def getPrincipal(self, id): if not id.startswith(self.prefix): next = queryNextUtility(self, IAuthentication) if next is None: raise PrincipalLookupError(id) return next.getPrincipal(id) id = id[len(self.prefix):] for name, authplugin in self.getAuthenticatorPlugins(): info = authplugin.principalInfo(id) if info is None: continue info.credentialsPlugin = None info.authenticatorPlugin = authplugin principal = interfaces.IFoundPrincipalFactory(info)(self) principal.id = self.prefix + info.id return principal next = queryNextUtility(self, IAuthentication) if next is not None: return next.getPrincipal(self.prefix + id) raise PrincipalLookupError(id) i had setup a local site with a pau with a prefix and an ldap auth, lookups for common groups like zope.EveryBody, zope.Authenticated, would in turn call queryNextUtility. however instead of returning the global site manager's principal registry, it would fail in the utility lookup. digging deeper, the queryNextUtility call is passing in a context of the authentication utility itself, which looks like a throwback to the older IComponentLookup adaptation, instead of the current thread local site manager with bases, thats currently used. When the auth utility is passed to queryNextUtility, the default site manager whose bases are queried is the global site manager, resulting in no utility found. Where as passing context none, gives the expected behavior, of looking up the current local site's bases for the auth utility in the global site manager. it appears to me, that this is a throwback/missed refactoring from jim's merge of the component registry refactoring.. can anyone confirm the analysis and the bug? this pattern is present in multiple places in pluggable auth utility implementation, and also, zope.app.security/zope/app/security/vocabulary.py:219 cheers, kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Sat, Apr 19, 2008 at 8:11 AM, Martijn Faassen [EMAIL PROTECTED] wrote: Jim Fulton wrote: [snip] can you elaborate with a few more sentences why? I could, but I'd rather not. I suggest reading: http://mjg59.livejournal.com/84586.html if you haven't already. I concur with Jim - let's avoid ExtJS as their license is not clear. When I studied th details of the ExtJS license, I came away with the same conclusions as this blogger before I read that blog. I was interested in the discussions surrounding it because of this; I'd already decided not to use it. Don't think that since they mention it's LGPL it actually *is* LGPL - it's clear their intent is different. ExtJS is not *actually* licensed under the LGPL. The LGPL appears nowhere in their source code; it has its own license. They seem to think they can invoke the terms of the LGPL and then restrict them further to forbid use in a larger framework. See also my comment here: http://reddit.com/r/reddit.com/info/6enr7/comments/ i found this jack's (extjs author) comments on this thread illuminating (more so the original livejournal link).. nutshell is as you said, that extjs is not released under the LGPL. All appearances, claims, and links on their site not withstanding... http://extjs.com/forum/showthread.php?t=27592highlight=license matt assay did a blog post which sums my opinion of their licensing.. http://www.cnet.com/8301-13505_1-9878693-16.html too bad, its a great toolkit. cheers, -kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: straighting out the SQLAlchemy integration mess
On Thu, Apr 10, 2008 at 1:31 PM, Andreas Jung [EMAIL PROTECTED] wrote: --On 10. April 2008 19:10:49 +0200 Brian Sutherland [EMAIL PROTECTED] wrote: Just adding my few requirements: - Integration into the component architecture in such a way that I can specify the db connection parameters in ZCML and that database reflection still works. I want to be able to get a handle on SQLAlchemy things by calling getUtility. Please *NO* database specific configurations within ZCML. We're running applications in up three or four different environments and I don't want to maintain instance specific configurations within ZCML. Either we pass such informations through environment variables or the database connections parameters are read from a configuration within the instance configuration. i still don't see the harm having zcml db conf in a base package, if you don't have to use it to setup your particular deployment's connections. -kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] straighting out the SQLAlchemy integration mess
On Tue, Apr 8, 2008 at 5:54 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Hi there, [I originally picked this up on a thread on zope3-users, but this deserves its own thread here] There are at least three approaches to SQLAlchemy integration with Zope: * z3c.zalchemy (Christian Theune) * z3c.sqlalchemy (Andreas Jung) * collective.lead (Laurence Rowe) All of these are in various states of brokenness. z3c.zalchemy doesn't work with SQLAlchemy trunk. collective.lead works with it, but only if you check out a particular branch, and not with sqlite. Quite possibly z3c.sqlalchemy has a release that actually works. One out of three is not bad... :) Then there's also mentions about WSGI-based integration, and I think in Plone, Alchemist probably also does its own integration... ore.alchemist works with sqlalchemy 0.4 series, and i've been doing z3 rdb only apps with it over the last year. i'm biased, but i think it has the easiest api integration of any of the others.. from ore.alchemist import Session thats it.. all you need for transaction integration with sa, no magic utilities to setup mappers, or tables. the rest is as documented by sqlalchemy. it goes on to provide additional zcml syntax for defining connections and binding them to sqlalchemy metadata, but usage is optional. as for the wsgi based integration, to get zope3 without the zodb, i use ore.wsgiapp which just defines a utility which is the traversal root. i'd like to refactor it to use the new zope.publisher paste support directly, as it currently it includes a bunch of boiler plate from a generated There must be a reason for this proliferation of approaches. What is it? We all get along, don't we? I know that the various packages are taking code and approaches from each other too. we all had different needs, some wanted to play in z2 land where broken egg requires are the name of the game, some in z3 land... some were just the first to arrive. i wanted and implemented higher level semantics to generate interfaces from tables, and vice versa, and automatically generate forms etc. Can't we work together more and at least come up with *one* package that works? Perhaps factor out some low-level commonality than then all share? Criticize one of the other packages until you're satisfied, and then retire your own package perhaps? I know the various packages add on their own approaches to configuration and might offer higher level container approaches. Those could be in different packages, sharing a foundation. In the end, I hope we will end up with just *one* integration layer, that is released, that works with Zope 2 and Zope 3 and a recent release of SQLAlchemy, that is documented, and that people know about. We can then offer packages on top of this that offer extra features. that sound good, i'd like to see a common base layer, providing transaction support, simple containers. cheers, kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: straighting out the SQLAlchemy integration mess
On Wed, Apr 9, 2008 at 9:15 AM, Laurence Rowe [EMAIL PROTECTED] wrote: The transaction manager here: http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tx.py Has support for TPC and savepoints. It is tested and works. The only issue with sqlite is that the default in the branch is to use two-phase commit and sqlite does not support this. Apart from that the module is completely self contained. The public interfaces to it is the two functions at the bottom, join_transaction and dirty_session. The idea of the dirty_session stuff is to prevent unnecessary commits when data is only read. Session writes trigger the 'dirtying' automatically with a SessionExtension: http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/database.py The downside of this approach is that the when you interact with the connection directly to modify data you must call dirty_session yourself. If this is a problem for you then you may set up the transaction to be in the dirty state initially. Thread based session management is used (scoped_session). There is fairly extensive testing of this and the transaction support here: http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tests.py I think it would be worth factoring out the threaded session support as well as the transactions. +1, the collective.lead transaction support looks nice. @Christian: I'm not quite sure what you mean by: - Database triggers as events I don't see how you could reasonably get a database trigger on the db server to instantiate a zope event on the db client. Perhaps the database could be persuaded to make a request to a URL on a trigger, but this seems a bit slow and maybe not a great solution. - Making SA 0.4 work with security proxies I don't know anything about security proxies in zope 3, but surely this is just a matter of what the base class is / the container implementation? I don't see why an SQL Alchemy mapped object would be any different to any other object. its more to do with the fact that proxies are restrictive by default, and the sa api likes to monkey attributes on instances. christian kicked off some nice work with the sa developers at pycon to get this behavior configurable in sa ( instrumentation branch) which obviate the need to remove the proxies before calling into sa apis on an object. @Martin: Should one phase commit be set as the default to make it easier to work with sqlite (and mssql)? Probably yes. Should the default be for sessions to start out `active` or `dirty`? If they start out `dirty` then existing 1.0 code should work as before. It'll probably be next week before I manage to get this tidied up and merged back to trunk. @everyone: If we can all agree to use the same basic session and transaction management then we should probably push for it to be included as a sqlalchemy extension module. sounds good, or failing that (due to additional dependencies), a common base package. cheers, kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Exposing a the simple publisher (Re: [Zope-dev] Re: Reducing dependencies of zope.publisher)
On Tue, Mar 25, 2008 at 9:19 AM, Jim Fulton [EMAIL PROTECTED] wrote: On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote: Security proxies: this topic may not be directly publisher related, It's not. but maybe it is. Nope. :) Somewhere quite low in the request handling of Zope 3 a security proxy is introduced around the objects being traversed. This is done by the default Zope 3 publication object, zope.app.publication.zopepublication.ZopePublication. i've deployed apps with a custom zopepublication in part to bypass security proxies, and its unfortunately not the only place that injects security proxies. the more difficult injection point to avoid is the one in zope/app/pagetemplate/engine.zopeTraverser Grok doesn't want security proxies, so rips them off again in a custom publisher. It'd be nice if there were a hook point that would enable us not introducing this proxy in the first place. There always has been, as I've mentioned many times. The same hook point allows use of Zope 3 without ZODB. These policies are provided by the publication object. It's a shame that the convoluted setup system made this so inaccessible. My hope is that zope.publisher.paste makes it *much* easier to use a different publications and thus a different set of policies. (I plan to update zc.zope3recipes to provide an instance recipe pased on paste.) I'm 99% sure that most or all of the simplicity to want has already been there for a long time or is there now with the simpler setup framework in zope.publisher.paste. Note that my proposal wasn't to simplify the publisher. I think it already is pretty simple and I hope the recent zope.publisher.paste work exposes the simplicity by stripping off layers of overly complex setup. My proposal was simply to extract some core functionality in a way that greatly reduces dependencies. I don't expect this stripped down version to be of interest to most of the zope community. I do think it might be useful to people with much more limited needs. I didn't the proposal because I thought it would be of general interest, but to ask permission. I want to do this refactoring, to avoid a (yet another) fork of the publisher. I should have made this clearer. this all sounds really nice. i've been doing rdb apps with zope with custom publications.. but getting the initial setup right for wsgi involved some dead chickens to reimplementing the the wsgi application setup that had zodb bits setup and event firing hardcoded. looking over the new zope.publisher.paste code, it looks like it also pushes the responsibility for application setup to the publication factory.. ie. zcml loading, application startup events. +1 cheers, kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3 without ZODB
try ore.wsgiapp in pypi, you provide a root utility and traversal begins from there, the zodb is never opened. the default publication looks up the app root via utility and traversal continues from there. i've been using it successfully for a number of relational apps without the zodb. hth, kapil On Jan 15, 2008 1:27 PM, Jim Washington [EMAIL PROTECTED] wrote: David Pratt wrote: Hi Chris. I was scanning the lists looking for posts similar to this. Were you successful in getting something like this to work? Anyone else document anything like this? I wrote a different main.py at some point about a year or so ago so both twisted clients and servers to could be started up using schemas for zconfig but am looking at possibilities without and with other non ZODB backends. I see Philip provided some clues for a mixin that could be used to glue the publisher's traversal mechanism together with an alternative storage. Many thanks. Regards, David I, too, am interested in this. I'm taking a hard look at Sedna, http://modis.ispras.ru/sedna/ , a multi-user XML database, which seems to fit my brain and my current xml-ish bent a bit better than ZODB or rdb. The python modules advertised don't work reliably enough for me, though I have hacked together a protocol module that works to my satisfaction so far. If anyone wants to play with it, I'll throw it into the zif collective on Sourceforge. I'm thinking it may be possible to do an elementtree (with full XPath!) interface to Sedna. Anyway, Chris, any pointers on interfaces and configuration would be very much appreciated. -Jim Washington ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
On Wed, 25 Apr 2007 16:13:43 -0400, Andreas Jung [EMAIL PROTECTED] wrote: --On 25. April 2007 21:51:24 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: In your (stripped away) example, I saw lots of magic (e.g. grok.context, grok.name, @grok.action). But readable and comprehensible magic...but I would not call that magic. For me (several years back), Zope's TTW capabilities have been a major reason why I got interested in Zope. Interesting ... i too got seduced by the zmi, before i realized it had the grip of an iron maiden. Had I then seen the nasty ZCML files so much liked in Zope 3, I would probably have turned away very rapidly. ZCML is a pain in the ***...that's why Grok is attractive for writing Z3 apps and attracting more people to Z3. amen.. part of the appeal of grok, for me at least, is that its basically a meta-framework for constructing your own domain specific languages. Is this so much harder than ZClasses? I believe no As someone who used ZClasses intensively, I believe yes. As so often, I disagree and must second Philipp. i'd agree with andreas but for one thing, restarting the app server for minor code changes is painful.. akin to going from python back to compiled languages. for all their deployment/development best practice faults, zclasses offered quick iteration. -kapil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Product doesn't work in zope 2.7 that was working in 2.6
this has nothing to do with zope. the problem is due to the severe monkey patching, use of eval, and other bad practices in this product. its monkey patched attributes into zcatalog and in doing so altered the modules namespace, replacing the id function with a string. which leads to the error, as zcatalog uses the builtin python function id to determine the current transaction and manage subtransaction thresholds for mass indexing. -kapil On Wed, 2004-10-13 at 20:54 +0530, Nagarjuna G. wrote: On Wed, Oct 13, 2004 at 12:56:50PM +0200, Andreas Jung wrote: Best to contact the authors of the corresponding directly. Well, the author (undersigned) doesn't know what to do. The question was not from the users of the application but from the developers. This product works perfectly till 2.6.3, starting from 2.6.4 and upwards this problem appears. Looking at the release notes did not indicate any changes to the API of catalogue product. Nagarjuna --On Mittwoch, 13. Oktober 2004 16:32 Uhr +0530 MET 2004-2005 [EMAIL PROTECTED] wrote: Can anybody please help me, Our product Named GNOWSYS is working perfectly in zope 2.6 but when ported to zope 2.7 it does'nt get instantiated. I guess the way we are cataloging our Objects is not correct The Traceback of the error that occurs when we try to instantiate our product is as follows Exception Type TypeError Exception Value 'str' object is not callable Traceback (innermost last): * Module ZPublisher.Publish, line 101, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Products.GNOWSYS06.GNOWSYS, line 475, in addGNOWSYS * Module Products.ZCatalog.CatalogAwareness, line 116, in index_object * Module Products.ZCatalog.ZCatalog, line 537, in catalog_object TypeError: 'str' object is not callable is there a specific way for cataloging Objects in zope 2.7 please let us know ___ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files
i believe you were referring to http://freedesktop.org/Software/shared-mime-info spec http://freedesktop.org/Standards/shared-mime-info-spec its a system wide shared mime database for use by applications (ie. both gnome and kde). apparently no python bindings. -kapil On Tue, 2004-10-05 at 10:42 -0400, Fred Drake wrote: ? I think there's a library from the Gnome desktop project for this (basically providing something like the Unix file command), but I don't know if there's a Python wrapper for the library, or an all-Python re-implementation. -Fred signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] RE: [ZODB-Dev] Subversion repository layout
On Tue, 2004-04-27 at 10:27, Martijn Faassen wrote: Kapil Thangavelu wrote: sigh.. debating over what the book says isn't very productive. my conclusions at the end of my previous email, namely that what this layout will accomplish for the zopeorg repository in terms of avoiding renames of checkouts will likely be fairly limited in pratice, still win me out against deviating from the standard layouts. I tried to understand this sentence a few, but I don't get it yet. So, are you saying you think we *shouldn't* use a custom layout and thus stick with the 'default' svn layout, or are you saying you think we should deviate from the default svn layout? i'm saying we should probably stick with the default layout. why? because the primary benefit of the alternative layout is to avoid having to do a rename while checking out the trunk of a project, on checking out from branches or tags, this is required anyways. and in my experience most of the checkouts will likely be on release branches, and tags anyways. iotw. its of little benefit considering the disadvantages of moving from the default layout. cheers, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [ZODB-Dev] Subversion repository layout
On Mon, 2004-04-26 at 15:48, Tim Peters wrote: [Jim] The standard subversion repository layout is by project: proj1 /trunk /branches /br1 /br2 ... /tags /tag1 /tag2 ... ... With this layout, when you want to checkout the main development branch (aka head) of ZODB, you do: svn co svn+ssh://svn.zope.org/repos/ZODB/trunk ZODB That is, you need to include /trunk at the end and provide ZODB as the name of the output directory so as not to get a directory named trunk. If you forget the /trunk, you'll get a checkout that includes copies of all of the various tags and branches, which could be huge. I suggest, instead to use the following layout: ... Thoughts? I read some subversion docs over the weekend, and so am sufficiently prepared to live with the oddities of a standard subversion layout. I think that if you make a non-standard layout, then everyone coming to, or going from, Zope from/to other subversion projects will be forever tripping over the uniqueness of Zope's setup. IOW, the existing subversion docs cover the standard layout quite well. If we do something unique, I'm afraid it becomes another piece of folklore that will be impossible to guess and difficult to find out about. i like the layouts jim's presented (specifically #2 of 3), i think when considering the subversion docs, the important distinctions are made between the directories used for branches and tags, as long as that information is clearly communicated the semantics are exactly the same. the subversion docs themselves outline multiple repository structures (for example the single project layout), although they do recommend a standard structure, the docs go through great lengths to convey a semantic understanding of subversion as a versioned filesystem, not a magic functional notion as is common with cvs. i honestly dont think anyone coming from/to a subversion system will have problems as long as the location of the trunk, tags, and branches directories for a project are clearly identifiable. quoting the svn docs. Lay out your repository in whatever way you see fit. Subversion does not expect or enforce a layout schemain its eyes, a directory is a directory is a directory. Ultimately, you should choose the repository arrangement that meets the needs of the people who work on the projects that live there. in the existing zopeorg cvs repository, most of the existing projects are python packages, multiples of which must be stitched together to make a working dev environment, using jim's layout avoids alot of needless renaming. on the flipside, it only avoids the renaming in the case of using the trunk, and while they are the only things being converted at the moment, from my experience most of the checkouts from zopeorg have been on release branches, afaik, and i believe jim wanted to continue with existing structure such that most of the toplevel projects are not python packages. so the benefits/comparative advantage aren't that strong in this case in terms of breaking with the common expectation of repository layout. two cents, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [ZODB-Dev] Subversion repository layout
On Mon, 2004-04-26 at 22:30, Tim Peters wrote: [Kapil Thangavelu] ... I like the layouts Jim's presented (specifically #2 of 3), i think when considering the subversion docs, the important distinctions are made between the directories used for branches and tags, as long as that information is clearly communicated the semantics are exactly the same. the subversion docs themselves outline multiple repository structures (for example the single project layout), Sorry, I haven't seen that. The Choosing a Repository Layout section does talk about many ways to organize repositories, like multiple repositories vs one, and putting all projects in a repository at top level vs grouping them into related subtrees. But in all these cases, the only structure for a project they discuss or illustrate has project/trunk, project/branches, and project/tags structure. there are numerous references throughout the docs to alternative repository structures, like having one with /trunk/projectname http://svnbook.red-bean.com/svnbook/ch03s06.html or several examples w/ pics without trunk, tag, branches at all, http://svnbook.red-bean.com/svnbook/ch02s03.html but regardless its true that the vast majority of the examples assume the /projectname/trunk /branches setup. although they do recommend a standard structure, the docs go through great lengths to convey a semantic understanding of subversion as a versioned filesystem, not a magic functional notion as is common with cvs. i honestly dont think anyone coming from/to a subversion system will have problems as long as the location of the trunk, tags, and branches directories for a project are clearly identifiable. I haven't used svn, and I'm more concerned about people like me wink: the docs assume a specific project (not repository) layout throughout. I'm not interested in svn for its own sake, it's just something I'll need to do my job. The closer the docs match the system I have to work with, the easier it will be to get started. imo, the docs dont assume one layout, they have mixed examples, with a majority of them given with suggested layout, reading past the copy/paste code though and i think it tries to make clear numerous times that its not about the layout its about the semantics and policy assigned to locations. for example here's a quote on creating branches Creating a branch is very simpleyou make a copy of the project in the repository using the svn copy command. Subversion is not only able to copy single files, but whole directories as well. In this case, you want to make a copy of the /calc/trunk directory. Where should the new copy live? Wherever you wishit's a matter of project policy. Let's say that your team has a policy of creating branches in the /calc/branches area of the repository, and you want to name your branch my-calc-branch. You'll want to create a new directory, /calc/branches/my-calc-branch, which begins its life as a copy of /calc/trunk. I can't say Jim's suggestions are bad, or good -- I can't judge them since I haven't used svn (you?). Going against the recommendation of the people who designed and coded the system seems a dubious step on the face of it, though. i've been using svn for almost 2yrs, for client projects the last year, and i'm about to convert over plone and the sf.net collective project (~150 Products) and around 200 committers over to svn. i think jim's proposed layout could be very helpful there, as typically people will be using unfamiliar gui clients (like tortoisesvn) and will be checking out the head of the products and nitting them together to create a working zope instance/dev enviornment, in which case avoiding having to fillin an extra dialog might be nice and pratical. but i'm going to try and solicit feedback on those project lists. quoting the svn docs. Lay out your repository in whatever way you see fit. Subversion does not expect or enforce a layout schema-in its eyes, a directory is a directory is a directory. Ultimately, you should choose the repository arrangement that meets the needs of the people who work on the projects that live there. That's at the end of the Choosing a Repository Layout section. As above, that section discusses and shows nothing but the standard per-project layout; the layout choices they do discuss in that section are the ones mentioned above (how to organize projects in relation to each other, and in relation to repositories). it does shows another layout in the choosing repository layout scheme section, namely the single project etc, which you could say jim's layout is adapted from.. ie. /trunk /branches /tags sigh.. debating over what the book says isn't very productive. my conclusions at the end of my previous email, namely that what this layout will accomplish for the zopeorg repository in terms of avoiding renames of checkouts will likely be fairly limited
Re: [Zope-dev] order of transaction aborts
shared/dc/zrdb/tm does not hijack the transaction mechanism it integrates with it. you should coalesce txn integration for your objects into a single txn integrator so you needn't depend on transaction message/jar ordering. -kapil On Tue, 2004-04-20 at 11:35, [EMAIL PROTECTED] wrote: Is there any way to influence the order of transaction aborts when you hijack the transaction mechanism in a similar way as Shared/DC/ZRDB/TM.py does? I have Folder and File like classes which make changes on the file system as a part of their operation. When within a transaction I make multiple changes to these objects and the transaction is aborted, I have to do some cleanup in reverse order as these operations were executed. AFAIK, the p_jar.abort() calls are made in the same order as the objects were registered in the transaction. Regards, Sandor ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Mon, 2004-04-19 at 13:33, Shane Hathaway wrote: On Sun, 18 Apr 2004, Kapil Thangavelu wrote: should we move this discussion to an ape specific mailing list? I'm happy with zope-dev and zodb-dev, but if there's a good reason to make a new list, that's fine. its a knowledge discovery issue, there's a lot of useful info ape info floating around on diseparate mailing lists which makes it hard to get a hold of, having a single mailing focused on ape would make it much easier for folks to get up to speed and see all the cool stuff that can be done and that people are doing with ape ;-) cheers, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 2004-04-14 at 10:04, [EMAIL PROTECTED] wrote: Kapil, Right now, the svn transactions are entirely contained within a single fileops operation: for example a mkdir connects to a transaction root, performs the necessary operations, and commits, all in one shot. ok, thats what about what i expected. not ideal but it works. Last night I took some more time to try and learn more about Ape's functionning (Where events come from, which interfaces are used for what, and TPC), so I'm starting to understand more ... The more I learn, the more I think closer integration between SVN txn's and Ape's TPC would be a good place to start before looking at adding features like history support and so on: defining a model for what happens in svn for each TPC related call (connect, vote, finish), and then as Shane had said, look at IFSReader/IFSWriter (Which I now call ISubversionReader/ISubversionWriter :P) to match. part of the reason i never used ape as a means for svn integration was was that this imo, mix of high level application operations with zodb storage level operations never seemed a proper fit as it required bypassing the storage interface for richer semantic operations. ie i see reverting a revision, tagging a content tree, or diffing mulitiple revisions as application operations. still, there have been the some compelling ideas here about using zodb/ape as an interface. Right now the fs implementation stores script commands that are cummulated upon connect() (I think?), validated as best as possible upon vote() and run upon finish(). I don't see why this couldn't be adapted to SVN txn's ... connect() = start a txn, vote() = validation (what this entails needs to be defined, could involve delta operations, revision number matching, etc ... ?), finish() = commit the svn txn. not exactly, you just start a txn, do whatever work, and commit in vote. see my previous message outlining txn integration difficulties, and why this is not ideal but currently the best option. Because we're within an svn transaction, there would be no need for fs style script command accumulation however, which is nice. sure. should we move this discussion to an ape specific mailing list? -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
its (cmfsvnbrowser) not what your looking for, if you want a versioning system integrated with plone (as i recall your original request) i still think working with zope version control (as i suggested earlier) is more applicable in the short term.. as an integrated example of doing object version control entirely in zope see, http://occams.objectrealms.net -kapil On Thu, 2004-04-15 at 06:36, Arthur Chan Chi Chuen wrote: cool, let me try the cmfsvnbrowser first thanks. =) Arthur On Wed, 14 Apr 2004 10:35:14 -0400, Jean-Francois.Doyon wrote Well there you go, perfect :) -Original Message- From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] Sent: April 14, 2004 6:49 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote: Hello, Hmmm, well it's as stable as Ape and Subversion are respectively :) I wouldn't call it stable no, it's something I did over the long week-end we just had, and that's about it :) Ape is at 0.8 and therefore becoming quite mature, I'd have to let others speak as to it stability however ... Subversion is also probably quite stable (It just reached 1.0), though I don't know how heavily tested it's been in a long running process (Might it have some memeory leaks ?) ... the svn apache server model is a long running process and is fairly stable on memory usage. the python bindings require doing some manual memory management, but the pool api makes it easy to deallocate arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has been in production by myself and others for almost a year and runs with a stable memory footprint. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 2004-04-14 at 19:14, Shane Hathaway wrote: On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote: My initial, uneducated thoughts on the topic were simplistic, but then I'm a big K.I.S.S. fan: simply pickle the entire object back and forth as one entity. This means for each object, there is one file on the fs. The benefit is greater simplicity ... the downside is that you couldn't check those files out of subversion and interact with them. I also have to imagine the former is faster ? If you store pickles, you can't merge, you can't store properties, in fact you can't even store folders as directories or keep track of references between objects. At that point, you'd do much better to just use FileStorage--KISS, after all. Ape's real utility is in breaking objects apart for storage. If you don't need that, you don't need Ape. But I like to think it makes the job of breaking objects apart for storage relatively simple. But if usnig the latter, then I'd think that in SVN there would be only 1 file, written by a specific mapper for a specific content type, say image. the data written to the file is such that if checked out, the file works, so I can open it in photoshop or something. I however, would simply put everything else in properties, if that makes sense at all. Zope properties, security information, and so on. 1 porperty, 1 piece of data. No need for reading/writing multi-line text. That's fine, although you'll need to distinguish Zope properties from other kinds of properties. For example, if some object has a class_name Zope property, you'd be in trouble if the system mixed that up with the class_name key of the object classification. i don't think needs to much worrying about, just prefix zope properties with 'zope:' much the same way svn does with its properties 'svn:externals' The only thing I'm not so sure about is this remainder ... Though if it really is a base64 encoded string, there's no reason not to put that in a property as well. That's correct, it's always base64 encoded (with some comments.) The benefits I see: - The filesystem reflects the object structure, no extra files lying around. Definitely. - a more consistent way to setup mappers/gateways: there's data, and there's everything else. Have a common/defined/smart way of handling everything else. I would recommend you defer this for a while. Lots objects don't easily fit this model. For example, what is the data of a CMF tool? We can make plenty of progress on Subversion without thinking about changing the way mappers are defined. - with the use of the properties related svn funtions, we better leverage SVN's features. Yup. another thing to keep in mind here, svn is basically a versioned fs, and in addition to node/content history tracking and it has facilities/functions for apply deltas to content, and recieving delta diffs back etc, but these apply to node/content bodies and not to properties. ie. there are no facilties for diffing properties, and this would need to be implemented in python. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 2004-04-14 at 10:44, [EMAIL PROTECTED] wrote: The property schema thing is a good point, though I'm not sure we could ever do anything about it, not with the purpose to help naive gui clients work better with the repository. agreed, its not something to worry about, and such naive clients are imo broken. By nature the object structure (Class instance) is not fixed, so the amount/name/data of properties could vary arbitrarily. This is after all the major benefit of an OODBMS. Fact is if one wanted a client to interact with a svn repository that stores zope objects, it would need to be fairly specifically designed for it ... How would a client (Say dreamweavnr with a subversion plug-in) know that when editing an image, the x and y size properties need to be updated ? What if someone monkey patches the image type to add some other property/attribute ? well i think its also useful to think of svn as a sychronization point, like an rdbms. for other processes in other languages to interact with the content, like doing rich transforms/classification based on the content and storing as properties. using proper names for properties i think avoids the issue of dealing with client overlap, i would treat properties as though they were in xml namespaces, ie serialize dublincore author to dc:author, zope localroles - zsecurity:localroles, etc. also its possible for zope to have total awareness of content changes done by external clients ( i depend on this functionality actually to reindex, get notification of deleted, apply wf to added content, etc.) but all of this happens at an application level not the zodb layer. All we could hope to do is find a consistent and predictable way to handle properties, so that clients would know at the very least how to read/write them, but not necessarily know which one does what. I suppose there's possible ways around that actually, by providing some way to describe properties and what they do and so on ... but that's beyond the scope of what I'm trying to do I think ... it is beyond scope, at min it requires a schema set for commonly defined properties which beyond the zope core properties are application specific. i wouldn't worry about to well into the future. -kapil J.F. -Original Message- From: Kapil Thangavelu [mailto:[EMAIL PROTECTED] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote: On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ? Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called properties. Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name .properties is thus confusing. Oops.) svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Thu, 2004-04-15 at 00:16, [EMAIL PROTECTED] wrote: Oh, a very good idea indeed! We'll have to look at that eventually. The mechanism you describe is preferable, but it should be noted that subversion properties are easily accessible using the clients. So long as said properties are human readable/writable, that's also an option. The main issue for me (And many others I suppose), is the fact that every single object type I use is either completely custom, or a monkey patched version of a built-in type (Notably OFS.Image for instance). So there would have to be a reliable serializer for other objects, which I beleive you already have, so that's OK :) i dunno if you use or have tried archetypes, but it has experimental support for generating the needed ape structures from its schema.. see archgenxml and archetypes/apesupport.. its pretty cool actually you cane go from a uml model straight to a content model with support. http://cvs.sourceforge.net/viewcvs.py/archetypes/Archetypes/ApeSupport.py?rev=1.6view=auto cheers, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Wed, 2004-04-14 at 19:28, Shane Hathaway wrote: In Subversion, is it possible to read/write a versioned object by unique identifier rather than by path? If so, it's a great blessing and we don't need a transaction script. not really, yes every svn node has an a node id, but there is no way to retrieve a particular node from the svn fs via node id. it is possible to compare to compare and see if their related, (part of the node id is a copy id which gets incremented when a node is copied). in short not really. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote: Hello, Hmmm, well it's as stable as Ape and Subversion are respectively :) I wouldn't call it stable no, it's something I did over the long week-end we just had, and that's about it :) Ape is at 0.8 and therefore becoming quite mature, I'd have to let others speak as to it stability however ... Subversion is also probably quite stable (It just reached 1.0), though I don't know how heavily tested it's been in a long running process (Might it have some memeory leaks ?) ... the svn apache server model is a long running process and is fairly stable on memory usage. the python bindings require doing some manual memory management, but the pool api makes it easy to deallocate arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has been in production by myself and others for almost a year and runs with a stable memory footprint. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote: On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ? Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called properties. Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name .properties is thus confusing. Oops.) svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: On Tue, 13 Apr 2004, Kapil Thangavelu wrote: since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. This is only true of FileStorage. Some other storage could implement ZODB versions with merging capability rather than locking. good point, just because hasn't been doesn't mean it can't ;-) although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? i'm also curious how you dealt with svn transactions as part of the ape integration work to date. The same way it tries to impose transactions on the filesystem: in the vote phase, Ape looks for possible problems and aborts early if it detects anything that will cause the transaction to fail. Obviously, this provides no guarantee, but covers many cases. i was more curious how jean-francois was doing the svn ops in fileops, as svn is fundamentally a transactional store (as opposed to the fs), ie is there some record boundary notion of ape signalling the end of serialization for an object set, or was each operation being conducted in a separate svn transaction. -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
granted the svn integration has lots of coolness factors including richer client integration, but things like zope version control (zope.org cvs) are already production quality and not so hard to integrate in for basic version control. -kapil On Tue, 2004-04-13 at 14:13, Arthur Chan Chi Chuen wrote: Hi all, I've read your discussion about version control, it seems a cool thing you guys making good progress. Btw, can I ask is the Ape using Subversion in Zope stable? how able CMF stuff? I wanna make/find a document management system which can provide some kinda version control in Plone. Thanks Arthur On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions. png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn are using what amounts to optimistic concurrency control which makes it impossible afaics, to get real txn integration, ie in zope's two phase commit strategy, the last chance for a participant to safely abort is tpc_vote, but there is no real way of knowing if the svn txn will suceed or not until its tried. if it is tried at this stage and succeeds then there is the possibility of a latter txn participant failing the tpc_vote and the txn being aborted, and if waits till tpc_finish (last part of two phase commit) and the svn txn fails it can hose the composite txn integrity. once svn supports dav locks, doing txn integration via resource locking as part of tpc_vote (or earlier) would be possible, till then.. i dunno, i can't see a way around this for real txn integration. i'm also curious how you dealt with svn transactions as part of the ape integration work to date. - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird
Re: [Zope-dev] Re: [Zope3-dev] Zope and zope
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? snip Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) +1 its probably a problem imo for mac users who are on a case insensitive fs. none of the alternative seem all that appealing though.. the comment about most z3 imports being prefixed with zope, suggests that any backwards porting with a goal of forward compatibility will require changing the existing z2 Zope package to something else, although sticking version numbers on package names doesn't hold much appeal for me. perhaps renaming z2 Zope-Core -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
fwiw, Simon Eisenmann checked in a SessionStorage product into the collective which does much the same. released under the zpl http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/ -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions.png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn are using what amounts to optimistic concurrency control which makes it impossible afaics, to get real txn integration, ie in zope's two phase commit strategy, the last chance for a participant to safely abort is tpc_vote, but there is no real way of knowing if the svn txn will suceed or not until its tried. if it is tried at this stage and succeeds then there is the possibility of a latter txn participant failing the tpc_vote and the txn being aborted, and if waits till tpc_finish (last part of two phase commit) and the svn txn fails it can hose the composite txn integrity. once svn supports dav locks, doing txn integration via resource locking as part of tpc_vote (or earlier) would be possible, till then.. i dunno, i can't see a way around this for real txn integration. i'm also curious how you dealt with svn transactions as part of the ape integration work to date. - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort. to me this is one of the fundamental benefits of using svn, giving users the ability to use interfaces like tortoisesvn (win shell extensions) or mac finder extensions to interact directly with content. - Leveraging SVN's property management. Content in SVN has properties, much like Zope does. I haven't looked at it yet, but I've noticed .properties file appearing ... I'm guessing those are the Zope properties, which would be better handled by subversion's property mechanism. And properties are versioned too ! definitely! In the realm of the wishful thinking, there's even more: Right now, HEAD (Latest/youngest revision) is always used and worked with. The really powerful feature I want to eventually
[Zope-dev] Re: Proposal: Move to subversion for source code control of the Zope and ZODB projects
fwiw, i've been able to get good results at migrating the plone repository and branches using the refinecvs migration script http://lev.serebryakov.spb.ru/refinecvs/ the cvs2svn script included with subversion had several issues with branches, although it was a few months ago (prior to svn 1.0) that i last attempted to use it. with a little luck plone will be on svn before the end of the month. i've also setup some one way cvs-svn sync scripts for mirroring zope.org cvs into an svn repository to allow for automated pull of dependencies via svn:externals. -kapil On Mon, 2004-04-12 at 08:44, Sidnei da Silva wrote: On Mon, Apr 12, 2004 at 08:11:44AM -0400, Tres Seaver wrote: | Lennart Regebro wrote: | From: Jim Fulton [EMAIL PROTECTED] | | Initially, I propose to move just the repository heads. Maintenamce | branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. | | What is the rationale behind not moving it all? | | Risk mitigation; we have significant support requirements for deployed | systems built around CVS for both 2.6- and 2.7-based sites, whereas the | head and Zope3 have no such inertia. We don't know enough about the | migration process to have any confidence that existing history / | branches, etc., won't be somehow messed up, which makes it prudent to | plan the migration around the already-unstable bits. Just FYI, Kapil has been doing a good job at improving the script that migrates from CVS to SVN, and we are ready to flip the switch to move Plone, Collective and possibly Archetypes to SVN. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB with twisted web.
On Fri, 2004-04-02 at 17:37, Dieter Maurer wrote: Syver Enstad wrote at 2004-4-2 11:38 +0200: I am checking out how to use ZODB with twisted web. I thought that I would have the DB instance globally accesible and call the open method to get a connection on each request. I thought that if I use connection.getTransaction().commit() before sending the response I will commit on the connection for that request. Is this necesarily true when using twisted web because it is single threaded and it seems that ZODB finds the correct transaction by checking the thread. This is true only, when you are working with local transaction mode (i.e. you are calling connection.setLocalTransaction()). Currently, this mode restricts you to a single transaction client. Neither relational databases nor other transactional clients understand this mode. Moreover, you cannot use DBTab to mount several ZODB storages. i wouldnt say it restricts you to a single txn client, local transaction mode with twisted allows for the primary goal of using single threaded twisted with zodb txn semantics bound to protocol instances/clients, and the txn framework is still perfectly capable, just that the resource integration of other txn aware resources needs to play well with zodb conn based txns, which basically rules out most of the existing zope products as they use a global accessor to the transaction as opposed to call getTransaction on a conn which would still allow zodb to play a txn authority/manager role. but at the level of using twisted and zodb directly those products wouldn't likely be all that useful. -cheers, -kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] strange path
most likely Concepto object id is not being set properly. this question should be addressed to [EMAIL PROTECTED] this list is for the development *of* zope itself not development with zope. -kapil On Sat, 2004-03-20 at 10:51, Garito wrote: Hi on a ZPT I put a here/absolute_url and these is the response: http://localhost:8080/Plantillas/Pruebas/Objetos///Minima the correct path would be: http://localhost:8080/Plantillas/Pruebas/Objetos/Concepto/Vistas/Minima What's happening here? TIA __ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question about _v_ attributes and database connections
fwiw, i think this is a viable solution (although you should not only scope connections to thread local but to da paths in the module level global) as there are problems with zope and das going away because of their volatiles.. it can lead to strange behavior, like say your in the midst of a long txn, the da conn is involved gets registered w/ the txn. during the course of the txn the da persistent object is ghosted, latter it comes back but it will do so with a different connection if used again, this is bad from an rdb txn isolation pov, because assuming any isolation it can't see the changes done with the other as yet uncommitted connection (still alive cause its ref indirectly from the zope txn itself). unfortunately this is arch. problem with zope and current rdb/da integration and the only real solution that i see is via module level global storage for conns. as for shutdown of these conns, easiest might be to register an atexit function, or a cleaner sweeper thread with last usage times and in txn status on the otherwise thread local conn storage. cheers, -kapil On Thu, 2004-03-11 at 06:56, Marco Bizzarri wrote: On Thu, Mar 11, 2004 at 11:49:34AM +, Chris Withers wrote: Marco Bizzarri wrote: I'm trying something inspired to that at the moment... I succeeded in installing an hack, very inspired from your code (but at a much simpler level) and some code in the SecurityManager, ?! Look in AccessControl/SecurityManagement.py, the getSecurityManager()... it does in that way. where I mantain a dictionary of connections, indexed by the result of thread.get_ident(). :-( I know, it is an hack :( Once a thread needs a new connection, either it is present in the dictionary or not. If it is present, give it to the thread and assign that to the _v_database_connection attribute. Otherwise, create a new one, put in the dictionary, and go on as before. When do these connections get closed? Never, for the moment. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Serving big files thru zope?
you could play with http://puggy.symonds.net/~srp/stuff/mod_auth_remote/ and have apache auth off zope. cheers, -kapil On Mon, 2004-03-01 at 11:06, Sandor Palfy wrote: I am also wondering about the security aspects of bypassing Zope to serve files - acess to some of the files we need to serve is restricted to particular users with particular permissions, and I cannot clearly see how this would be possible to accomplish without Zope's security machinery. Same situation here. Is there any way to provide authentication information for Apache from Zope (which works at least with cookie based auth)? Regards, Sandor ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Custom class: cut,copy,rename?
On Mon, 2004-03-01 at 13:59, Ian Beatty wrote:
Greetings.
I've created a package in Python with some basic classes. They work in the
ZMI, except for the fact that the ZMI paste and rename functionality fails
with the message The object xxx does not support this operation.
I've dug into the source code for standard types ('OFS.Folder',
'OFS.SimpleItem', etc.) and discovered some tantalizing bits (such as
'manage_renameObject' in 'OFS.CopySupport'), but I can't figure out how to
put it together to make my classes renameable and pasteable. I'm rather
surprised that behavior doesn't come automatically when inheriting from the
standard base classes.
One of my folderish classes subclasses the following bases:
OFS.ObjectManager.ObjectManager
Products.ZCatalog.CatalogPathAwareness.CatalogAware
OFS.PropertyManager.PropertyManager
OFS.SimpleItem.SimpleItem
Am I not inheriting from the proper set of base classes? Is there an easier
way? According to the ZDG (2.4 edition, vs. my Zope 2.7),
OFS.SimpleItem.Item (subclassed by OFS.SimpleItem.SimpleItem) is supposed to
provide cut-and-paste functionality. So, how might I be breaking it?
as i recall the default copy paste behavior is a bit arcane in that the
verify tries to assert the object is indeed a registered meta_type (ie
reg. in initialize) so that it can verify permissions, see cmfcore
folder code for an example of making a custom container which works
around this (basically just override _verifyObjectPaste), or just
register the objects.
cheers,
-kapil
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non Bloating Page Counter
On Friday 08 November 2002 01:55 pm, Dieter Maurer wrote: Brian R Brinegar writes: We've had requests from several of our users for the ability to have a drop in page counter within zope. However creating a page counter python script which increments some value in zope will bloat the ZODB. Solutions exist where values are stored on the file system or in a database. Unfortunately our users don't have file system access and it is unacceptable to expect them to request a database account and setup database connections and methods just to create a page counter. I would like to create a Page Counter product that doesn't bloat. If a product is created that doesn't subclass History or UndoSupport does it still bloat? It does. The bloat is a consequence of how FileStorage works (I appends changes at the end of the file and does never override something). You need a different storage (a non-undoable one) to prevent this behaviour, e.g. BerkeleyStorage or OracleStorage. is there a useable undoable storage? When your load is light and your counter consists justs of an integer, then your bloat is only several dozens of byte and you may be able to live with it if you can live with that, then you should try to use a subclass of lib/python/BTrees/Length.py more efficient pickling state and app conflict resolution. stepping up beyond that while remaining in the zodb means using something like the strategy casey suggested of updating in memory variables and committing them periodically (and you definitely want conflict resolution for something like that on your persistent ob). -k ___ 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] User Module
first, these questions are better directed at [EMAIL PROTECTED], this list is for discussion for development of the zope server, not development on zope. second, another good resource, the #zope irc channel on openprojects is a wealth of friendly helpful people. -kapil On Thursday 07 November 2002 08:36 pm, Karthikeyan wrote: Thanks Lennart and Wei for the comments. But i need to design something to show and convince somebody. Pls help me with some modules to start. Lennart, The acl users you are taking about is coming with the management screen. I need to create a page to register a person and make him login thru my page. Pls let me know. Thanks ___ 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] 2.6 MIA
whats the release plan for 2.6? is it time for another alpha/beta release? curious, kapil ___ 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] DirectoryViews for Zope2.6?
On Tuesday 04 June 2002 10:24 pm, Robert Rottermann wrote: I agree with you. And they depend on CMF only very ligthly. So taking them out of CMF should be easy. indeed it was. http://www.zope.org/Members/k_vertigo/Products/FileSystemSite i don't have the unit tests ported over, but they are included with the distro. -kapil Robert - Original Message - From: kapil thangavelu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 3:09 AM Subject: [Zope-dev] DirectoryViews for Zope2.6? hi folks, i was wondering if there is interest (or possiblity) of including directory views in zope2.6. i've been using them for team development with zope, and i've come to think their a fantastic dev. method in combination with cvs. any takers? cheers kapil ___ 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] DirectoryViews for Zope2.6?
hi folks, i was wondering if there is interest (or possiblity) of including directory views in zope2.6. i've been using them for team development with zope, and i've come to think their a fantastic dev. method in combination with cvs. any takers? cheers kapil ___ 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] putting the 'two' back in tpc
+1 for adding _vote() to TM.py all XAs/DMs should have voting privleges, even if they don't exercise such. the default behavior should be due to nothing, for as with people in a democracy most tm subclasses won't vote. -kapil On Tuesday 04 June 2002 12:54 pm, Leonardo Rochael Almeida wrote: In a chat with Kapil at #zope we came to the conclusion that most Zope database adaptors don't really implement two phase commit, because they make no effort, during the 'vote' phase (the first phase of the tpc) to make sure that the commit will go thru without errors. For example, if you have the following schema in postgresql: CREATE TABLE passwd ( username character varying(64) UNIQUE, password character varying(64) NOT NULL, roles character varying(255), Constraint passwd_pkey Primary Key (username) ); CREATE TABLE userproperties ( username character varying(64) NOT NULL references passwd (username) DEFERABLE INITIALLY DEFERRED, propname character varying(128) NOT NULL, value text NOT NULL, ); This schema allows an entry in the 'userproperties' table to exist without an equivalent user in the 'passwd' table before the end of the transaction. If, on commit, there still isn't a user with the same 'username' on the 'passwd' column, postgres will raise an error and won't let the commit go thru. Now all the current DA implementations that I know of call the database commit only in the second (or finish) phase of the tpc, which will result in a locked down Zope, as Zope is not very much fond of people bailing on him on the second phase. Now the correct solution for this, as far as postgres is concerned, is to execute the query, 'SET CONSTRAINTS ALL IMMEDIATE' in the 'vote' phase, since no other query will be executed between this query and the commit. Postgresql will raise an error while trying to execute this query if any coinstraint is yet to be satisfied, so Zope will be able to cancel the transaction to all those registered in the transaction machinery. And if the postgresql documentation is correct, 'SET CONSTRAINTS...' is an SQL92 and SQL99 standard, so other db's might be able to benefit from this. The problem is that lib/python/Shared/DC/ZRDB/TM.py doesn't provide a _vote() slot which should be called by tpc_vote(). TM documentation should mention that this slot should be overriden, just like _finish() and _abort(). It should also mention why this slot should be overriden (consistency this, consistency that, yadda yadda..). The nazi bastard in me wants the default implementation of this slot to raise an error to remind people to override it. If your DA doesn't need, or can't, implement a _vote() for some reason, you should explicitly override it to do nothing. However I know that breaking other people's DA is not nice :-) The not so nazi bastard in me says that the default _vote() implementation should zLOG a warning about '_vote()' not being implemented, but I know that even this might be too much to ask, since logfiles everywhere would go crazy. Anyway, this may be a little late, but I believe that implementing a do-nothing _vote() that is called by TM.tpc_vote() is a small and unintrusive change but a change that is important enough to deserve to be included in 2.6, so that DA authors take notice and implement it where possible. I'd volunteer to make this change myself if my commiter's agreement had been commited (I'm looking at you Paul Everitt). I know that I'll bug the Psycopg guys once this change is thru. Leo ___ 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] python question
On Saturday 27 April 2002 08:44 am, Andy McKay wrote: Look at pydoc http://www.google.ca/search?q=pydochl=enmeta= last i tried it, pydoc has issues with some zope stuff, its also distracting and educational to realize how much support stuff zope mixins... happydoc is a nice tool that differs mainly in that its analyzing structuring rather than importing and inspecting ala pydoc. -k - Original Message - From: Dirk Datzert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 26, 2002 10:39 AM Subject: [Zope-dev] python question Hi, does anybody know a good programm or the command to create documentation of python classes (api-documentation like javadoc) out of the python code ? Thanks, Dirk ___ 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 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 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] How about a Bug Day this Friday?
On Monday 08 April 2002 12:40 pm, Brian Lloyd wrote: Hi all - A while back I posted a summary of the semi-regular bug days we'd like to start having: http://dev.zope.org/CVS/BugDays We are planning to have the inaugural bug day this Friday (April 12th) from around 9 a.m. US /Eastern until we've all had enough :^) If things go well, I'd like to see this become a regular thing (say the second Fri. each month). Whaddya think? sounds great. cheers kapil (irc hazmat) ___ 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: [Zope] isecure XML-RPC handling.
he's testing against zope.org and the traceback is enclosed html comments, which probably does mean it is debug mode. as for the concerns... i leave that to others. -k On Tuesday 02 April 2002 12:18 pm, Chris McDonough wrote: You are running Zope in debug mode (with the -D switch in the start file). This is the default. Please try running Zope in non-debug mode (remove the -D switch) and try this again. - Original Message - From: Rossen Raykov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 2:33 PM Subject: [Zope] isecure XML-RPC handling. Zope is not handling correct XML-RPC request. Even the example from http://www.zope.org/Members/Amos/XML-RPC is not working. Even worst if a request like this one in the quoted example is send to the web server it will report information about the local server installation and the internal network. Included are a request and response to www.zope.org. As one may see the server is installed in /usr/local/base/Zope-2.3.2-modified/ and it rely on 10.0.11.3:1380 for request processing. All this may be useful debug information but it is not acceptable for a production server! I'm not familiar with Zope and I cannot say is it only a configuration problem or it is a problem in the code. I do not have time to investigate that but a similar result may be achieved with the distribution offered for download. Please let me know if I have to send this bug information to some one else. I would like to be informed and when this issue is resolved so I can announce it on Bug-Traq. Regards, Rossen Raykov cut here $ telnet www.zope.org 80 Trying 63.102.49.33... Connected to www.zope.org. Escape character is '^]'. POST /Foo/Bar/MyFolder HTTP/1.0 Content-Type: text/xml Content-length: 95 ?xml version=1.0? methodCall methodNameobjectIds/methodName params/ /methodCall HTTP/1.0 500 Internal Server Error Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2) ___ 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] Underscore trouble.
rename your columns in the select statement, this question belongs on [EMAIL PROTECTED] -kapil On Tuesday 12 March 2002 03:23 am, Romain Slootmaekers wrote: Yo, We have to connect to an existing database from zope. In this database, some of the fieldnames start with an underscore (fi _url). Zope sees these as protected and raises an exception when we try to access the tables with a select... Is there a way to disable this Zope 'feature' on ZMySQL methods ? TIA, Sloot ___ 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] Help System Searches
would it make sense to make the help system still allow searching but do storage in a mounted zodb ? cheers kapil On Saturday 09 March 2002 10:55 am, Chris McDonough wrote: There is no way to fix this? What other problems are there with the help system? Not that I can think of. Other problems with the help system are presentation, mostly. Would it somehow be possible to make the helpsystem ignore versions? No, unfortunately. It uses the Catalog, which is based on ZODB, and it puts a Catalog instance into the main FileStorage, which is undoing and versioning. It then proceeds to do writes to the database when it appears that all you're doing is reading a pre-existing page. If you're in a version at the time, a set of objects will be written into the Catalog and into other places in instance space that have version. This is a bad pattern, and the only way to fix it is to prevent it from happening, which requires some helpsystem architectural changes that amount (IMHO) to a rewrite. - C ___ 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] Transaction Bugs
I wrote some unittests to investigate some odd transaction behavior i noticed while doing unittests of integrating non sub transaction aware objects, and to insure proper txn behavior. these tests test the transaction system independent of the rest of the zodb and test failure modes as well. i've found a few bugs. 1. TM.py ignores calls to tpc_abort. this i believe is the likely cause of most of the rdbms integration problems that are referenced above as TM.py generally forms the integration point between db adapters and zope's transaction framework. if an error occurs in the two-phase-commit protocol, the database adapter will never recieve a finish/commit or abort message, and will therefore (due to how TM works) never be able to register again for a zope transaction. 2. A Non Sub Transaction aware object (including any TM derived object) that participates in a sub-transaction will recieve a tpc_finish message (which for TM derivatives calls _finish) as part of the subtransaction commit process. this means that if the outer transaction is latter aborted, there will be a loss data integrity. 3. As part of the commit process for a transaction involving subtransactions, any objects registered since the last subtransaction commit will be involved in an implicit subtransaction commit. if an error occurs during this implicit subtransaction, none of the objects registered previously to the last explicit subtransaction commit will recieve any messages. i'm not sure totally sure this is a bug since any calls to explicitly begin a new transaction should abort the objects that haven't recieved any transaction messages. in a zope setting this is done automatically, however standalone users should be aware of this. i've posted a modified TM.py to my zope.org member page that contains fixes/workarounds for problems 1 and 2. http://www.zope.org/Members/k_vertigo/ShortStories/Transaction/ in addition the unittests i've been using are posted there as well. i'll commit these changes to TM.py latter today, but have posted the above to zope.org for those who don't want to immediately upgrade. actual fixes for problems 2 and 3 i'll leave to ZC. if you're using a rdbms with zope, i would recommend installing the modified TM.py in replace of the exiting TM.py at lib/python/Shared/DC/ZRDB/TM.py. i would appreciate any feedback from rdbms users who were previously experiencing problems. if this does not solve your problem, and you believe its the fault of the transaction system, please email me. i don't use an rdbms with zope, but i'm happy to further investigate. cheers kapil thangavelu ___ 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] Zope 2.6 planning - call for contributors!
On Wednesday 06 March 2002 04:58 am, Joachim Werner wrote: Hi! What I'd expect from Zope 2.6 depends a bit on when Zope 3 will be available. If we are talking about a couple of months, I'd prefer only having bug fixes in 2.5.x (and no 2.6 at all). If we are talking about more than half a year, or even a year from now, things look different. The problem is that all time that is invested into Zope 2.6 will be lost for Zope 3 development, but on the other hand I can't imagine how I would convince a customer to fund Zope 3 development if the results will not be useable soon. So what we actually need is a Zope 2.5.x to 3 migration path and plan that justifies investments in either Zope 2.6 or Zope 3. For that, we'll have to answer a few questions, like - Are there any components in the Zope 3 development cycle that can be backported to the 2 series? personally i would be interested in a backport of the component architecture, but i think that focusing development efforts on the zope3 core, is a more useful allocation of resources. zope3 will be ready faster the more people are willing to work on it. i know that i've been guilty of having not worked on it, since i have need to finish developing projects now on zope2 before i get to work on it. that said, i really like some of the proposals on the table for 2.6, but i just don't think that backporting zope3 to zope2 is a good use of people's time. - Can we build stuff into 2.6 that makes people start thinking the Zope 3 way? - ... in this regard the component architecture would make the most sense... but again it would be fairly much a developer resource, and without the components, services, and utilities themselves it would just be lookup and structure to applications. most of whats in zope3 currently is architecture. I don't want Zope to end up like ArsDigita's ACS. They had a perfectly working 3 series that had all the features you'd expect, but was butt ugly in terms of the actual implementation. Then they started from scratch (like Zope is doing now) and built ACS 4, which was well-designed, but buggy as hell and had only core functionality. The plugins had not been ported yet. Then they started from scratch again and ported to Java (which Zope will not do I guess). regarding the acs4 there were many plugins (dude, packages is the preferred nomenclature ;) ported to the acs4 architecture. in fact there are more of them then there were for the 3x platform (partly in due to improved modularity). that platform still lives on and thrives today in the form of the openacs. and includes some services and functionality in the core that i hope zope3 will bring to zope land (package management, workflow, calendaring/events, etc...) the move to java and the fall of arsdigita came as direct result of tasting too much of that poisoned apple, known as venture capital. Currently there are 500 or so freely available Zope add-ons on zope.org, which will most probably not work on Zope 3, at least not with the 3X series. And there are even more non-free Zope products people have built on the 2 platform. I have the feeling that many of the add-ons will not be needed for Zope 3 because Zope 3 will do better out-of-the-box. But for many others there must be a migration path. i don't know how much discussion there has been on this, but its something worth discussing in more detail, namely the use of the ZopeLegacy system for zope2 products. when things are a little more settled down for zope3, an excellent piece of documentation would be a product porting guide. Let's take the database adapters. If Zope 3 does not support the major databases from the beginning, it might not get the momentum it needs. completely apriori, i think these will be a fairly easy thing to port ;) . Slightly off topic, I think what Zope (2 AND 3) need really urgently is another layer on top that delivers what the CMF (IMHO) did promise but not deliver to the extent I had expected: A solid foundation for Content Management Systems. just curious, what do you see as the problems with the cmf? snip good stuff and removed cross-posting cheers kapil ___ 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] Re: [ZODB-Dev] Replacing bobobase_modification_time
On Tuesday 08 January 2002 06:47 am, Chris McDonough wrote: I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute. It might be better to cause common Zope objects to do what Casey proposes (maybe via SimpleItem) as opposed to making folks keep app modtimes for those and as opposed to changing the semantics of bobobase_modification_time. In Zope2, this would be achieved via a mixin named something like Modifiable mixed in to DTML Document, File, etc. this sounds like a much better approach to me. the only question i have then, is how to hook modification times (as opposed to storage timestamps) without messing with Transaction.py? cheers kapil ___ 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] Re: [Zope] [Bug] bobobase_modification_time unreliable to catalog
On Monday 07 January 2002 06:20 am, Casey Duncan wrote: On Saturday 05 January 2002 08:15 pm, kapil thangavelu allegedly wrote: On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote: This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this: - Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time. - Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3. This will fix the aforementioned bug and get rid of an API anachronism. Thoughts? sounds good, i played around with an implementation to do the above. i'm not posting it here causes its inefficient, although i'm happy to email it to anyone who's interested. it basically added three methods. [snip details] For memory concerns, couldn't you just store the DateTime as a floating point number? This would incur just a small overhead to create a DateTime object when the value is looked up. I am interested in seeing this code. From my perspective it seems overly sophisticated. I'm interested how you derive the registration time in the first place. your right, what i did was overly complex. i took your suggestions and simplified to the following two methods, which stores the txn registration time on the object as a float. it looks like an ok solution, imo. it doesn't do much for newly created persistent objects for which it falls through to the behavior of bobobase_modification_time and returns the current time. in PersistentUtil class in lib/python/App/PersistentExtra.py new method from Acquisition import aq_base def getModificationTime(self): ob = aq_base(self) if hasattr(ob, '_p_changed') and ob._p_changed: return DateTime(self._p_registration_time) else: return self.bobobase_modification_time() in Transaction class in lib/python/ZODB/Transaction.py altered register method def register(self, object): self._append(object) object._p_registration_time = time.time() cheers kapil ___ 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] Re: [Zope] [Bug] bobobase_modification_time unreliable to catalog
On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote: This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this: - Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time. - Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3. This will fix the aforementioned bug and get rid of an API anachronism. Thoughts? sounds good, i played around with an implementation to do the above. i'm not posting it here causes its inefficient, although i'm happy to email it to anyone who's interested. it basically added three methods. 1. getModificationTime to App/PersistinentExtra.py 2. is_registered(self,object) to ZODB/Transaction.py 3. get_registration_time(self, object) to ZODB/Transaction.py add one data structure to Transaction.py, a registration_times dict. when objects are registered they get a DateTime registered with them that gets added to registration_times based on their position within the registered objects list (_objects). another solution might be a weak ref. keyed dict. so getModificationTime checks if the object is registered in the current transaction if it is it calls get_registration_time, else it falls through to bobobase_modification_time. there are two inefficiencies one is memory because of DateTime for every registered object and two is computational from the lack of a uniform (across subclasses) hash function for persistent objects which results in traversal of the registered object list to identify if an object is registered or not (and to determine position to figure out the index into registration_times). a much better solution memory wise would have the transaction.py keep a DateTime for its initialization and then have registered objects store registration times as deltas of that. i'm not sure what the better solution is in terms of the computational issue. but as is this solution doesn't seem scalable to me until the computational issues can be handled. cheers kapil -Casey --- Dieter Maurer [EMAIL PROTECTED] wrote: I just discovered that the value cataloged for bobobase_modification_time is often wrong: The cataloged value is not the time of the current modification but that of the previous modification. I expect that this is because bobobase_modification_time is updated when the transaction is commited while the values to be cataloged are determined before the commit. Do not trust the cataloged bobobase_modification_time! Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ___ 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 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] References, persistence, BTrees
Hi jeffrey, perhaps it might save you a bit of trouble. i've written a publish/subscribe event channel that seems to have must of the functionality listed below although it does use the techniques that you wanted to avoid. its at http://www.zope.org/Members/k_vertigo/Products/EventChannel at the moment its purposefully a simple publish subscribe model with filters. object references are stored via physical path and resolved via unrestrictedTraverse. On Thursday 03 January 2002 04:49 pm, Jeffrey P Shell wrote: I'm experimenting with an event notification service based on a publish-subscribe model for some projects I'm working on. When a subscription comes in, a 'Subscription' object is made, that basically looks like this: class Subscription(Base): def __init__(self, subscriber, eventType, filter=None): self.subscriber = subscriber self.eventType = eventType self.filter = filter def __hash__(self): return hash(self.subscriber) \ hash(self.eventType) \ hash(self.filter) 'subscriber' is a reference to the subscribing object, and it's very likely to be to an object in the ZODB. Is it wise to have more than one persistent reference to a single persistent object? I swear that I had once heard Jim say (vocally) that you could do references like this in the ZODB now. I'm trying to avoid using Paths because objects have a tendency to move around[*], and I have performance concerns for a single event service object to have to call 'unrestrictedTraverse' to every subscriber. yes, this a concern and depends on usage. i generally don't have many listeners to a particular event. when this has been an issue, i instead chain event channels and stick events in an event queue, which periodically gets flushed from a zeo client script. currently i'm doing this for a subscription model which works well since the subscriptions that way get sent out all at once, instead of bombarding the end user with lots of emails. [*] (it's due to the annoyances with manage_beforeDelete() and friends that I'm writing this tool.) Second question: If I use the hash of the Subscription as a key, is there any advantages/disadvantages with using an IOBTree to hold Subscription objects instead of a PersistentMapping? memory usage would probably be an advantage over large numbers of subscriptions, but i'm not qualifed to answer... cheers kapil ___ 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] A modest proposal: Replace medusa with Twisted
On Thursday 11 October 2001 03:30 am, Itamar Shtull-Trauring wrote: kapil thangavelu wrote: twisted is GPL and zope is not gpl compatible and that does not appear to be changing despite some mention from zc about trying to achieve compatiblity. Twisted is LGPL, and it might be possible to license it under something that will work with ZPL. I don't think this will be an issue if it comes to it. itamar, thanks for the license clarification. i didn't mean to suggest that its not a good idea to work on it. i was hoping that someone from zc would give some sort of status update to paul's statements from http://aspn.activestate.com/ASPN/Mail/Message/622793 june. kapil ___ 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] ZPL2.0
Only a little bit more arm twisting needs to be done in order for RMS to approve ZPL 2.0 as GPL compatable. We're very close, it's just sometimes, tricky to get a straight answer when speaking in legal terms. and there was much rejoicing:) seriously, i'll buy a round for those involved who show up at ipc10. dealing with RMS is tricky period. kapil __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ___ 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] A modest proposal: Replace medusa with Twisted
On Wednesday 10 October 2001 08:09 am, Michel Pelletier wrote: Just to throw out another idea, Amos has discussed with me in the past the idea of replacing medusa with Apache 2.0. Compelling as many of Twisted's features may be, Apache 2.0 as far as i can tell supports many of them as well (except perhaps jython integration, which is a pipe dream anyway for Zope). Apache has the upshot in that it is rock solid, tested by millions, trusted by even more, and no doubt one of the most actively developed peices of software there is. For ZC the upshots of 1) not needing to maintain it, and 2) it being a excellent marketing tool outweight many technical benifits that twisted may have that Apache doesn't (I'd like to know what the differences are, however). For example, does twisted do URL rewriting? proxy? process/thread job control? i'd never thought i'd see the day, open source software advocating the inclusion of other open source software because of marketing dictates. I'm not dismissing the idea, I'm just pointing out an alternative to Itamar's alternative. ;) my alternative to your alternative, is aolserver and mozilla. no mozilla isn't a webserver, but why should zope be either. cheers kapil ___ 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] [ann] developer tools
Developer Tools release ExtSearch/ExtIndex - Allows FS search from zope, integrates with swish++, includes a pluggable index and standalone version EventChannel - simple publish/subscribe system for zope with different channels and filters. SQLEngine - loads up sql methods from the fs, and provides a container for them, currently hardcoded to openacs's query xml syntax, but those who llike snakes should have no problem adjusting to other formats. License: GPL documentation on these varies, most integrate with the help system to provide documentation. download: http://www.zope.org/Members/k_vertigo cheers kapil thangavelu ___ 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] Web Services for Zope
On Wednesday 26 September 2001 04:41 pm, Andy McKay wrote: trying-to-auto-generate-a-wsdl-from-my-product'ly yours they're is a python script/product on ibm.com/developer that will automate much of the wsdl generation or you. its linked from one of uche's web services articles. its under the IPL (ibm pl). hth kapil ___ 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] Web Services for Zope
On Thursday 27 September 2001 08:15 am, Brian Lloyd wrote: Can I ask what the current status of the WebServices for Zope project is? http://dev.zope.org/Wikis/DevSite/Projects/WebServicesForZope/FrontPage Wiki says I had been shooting for something at the end of September, but that has been overtaken by events :( I'll be trying to work on this on an as-possible basis trying-to-auto-generate-a-wsdl-from-my-product'ly yours -- Andy McKay. Well... the status is that I'm trying to work on it on an as-possible basis :) The problem is that it hasn't been very possible for the last few weeks. i've been very curious, what the plan is for attacking the no magic problem described on the wiki. my understanding is this isn't possible without altering the publishing process. i guess i was curious if the component based publisher that was talked about at ipc9 was ever going to see the light of day or if there was another strategy that would work as well. curious, kapil thangavelu ___ 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] pluggable indexes and ranking
i've hooked up some external indexing machinery to zcatalog via a pluggable index. i get backed ranked results and i'd like not to loose the ranking info, but i don't know how to return a result set that preserves this information. any ideas? -kapil ___ 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] exceptions on windows
i've always been curious why zope on windows with a bundled python seems to have problems with finding the standard lib exceptions. does anyone know why? for example from exceptions import SyntaxError class MySyntaxErr(SyntaxError): pass in a product generates an import error. (i last noted this behavior on 2.2, haven't used windows since...) thanks -kapil ___ 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] Using Zope-modules in Python
Thomas Weholt wrote: Hi, I want to use some Zope-modules in plain Python, no web-stuff, namely ZODB and Persistence (maybe others too ). I've installed BeOpen Python 2.0 and Zope 2.2.2. I want to import the Zope-modules, but adding the C:\Program Files\WebSite\lib\python-folder to sys.path just doesn't cut it. I get an import error. Running on Windows 2000. Any tips, hints or guides wanted. Thanks! a good place to start http://starship.python.net/~amk/zodb/index.html kapil ___ 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] MailHost Improvements
There has been intermittent talk of improving mailhost's ability to scale. i just wanted to solicit some comments to some ideas for improving mail host performance. Stage I. Persistent Socket 1. make the smtp connection persistent 2. preface sending mail with a 'noop' operation to verify connection status 3. overide __setstate__ to open connection i'm not sure if this will yield any real world benefit but i like the style better than opening a new connection for every new message. Stage II. Transaction Aware 1. Store sent mail in a volatile 2. on transaction commit begin (tpc_begin), send all mail, if error abort transaction 3. reset volatile again i'm not sure of real world performance, but the design seems better and the added benefit that it will play nicely with the transaction machinery and not send unesc. emails. Stage III. Intelligent Q. aka the BulkMailHost 1. implement mailer thread / sole function to send mails from queue and intelligently manage a outgoing queue and deferred queue. 2. implement extensions to sendmail tag for immediate sending of mail which will wake/signal mailer thread after depositing into outgoing q. extension options are 3. mailer thread on a timer, so it will wake on either a sendmail tag with immeadiate extension or on timer expiration and send mail from queue, messages with error due to connection or placed in deferred queue. messages with undelivarable errors are either deleted or placed in a deleted queue. 4. all queues are viewable and manageable from the management interface. obviously this makes the sendmail tag async to the message being sent. i'm not sure if this something that really should be implemented in a ZODB default file storage due to the high write nature of the system or just dumped to the fs. again this seems questionable also because a proper mta should be operating on a store and send principle (qmail/postfix). comments? hmmm... looking through the source of the 2.2.2 mailhost i see a scheduledSend method, anyone know what this is from/for? Cheers Kapil ___ 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] Re: [Zope] Container Class questions
Dieter Maurer wrote:
Robin Becker writes:
I would like to add properties in a property sheet, but cannot find a
neat way to see the properties on the base object and on the
propertySheet.
So I would like my properties to show
id
title
and the properties on my basic properties sheet.
I can easily add properties directly to the object during the Thing_add
and Thing_addForm and these appear on the properties tab for added
objects.
How do I get a tab for the property sheets?
I am not sure, I understand precisely, what you want to reach.
ZClass properties are managed on distinct property sheets.
I do not know of a neat way to present (and change) properties
from different property sheets (other than adapting the
"manage_PropertiesForm" manually).
I wrote up some code (dated) to present generic forms for changing
zclass properties, code to follow. i generally use it just to get a fast
prototype for a system, example: picking a property sheet and harding
coding a link to the second method. yes this code does find base class
properties (including stuff like webdav, etc), or at least it did last
time i used it (era 2.1.6).
hope this helps
Kapil
three methods
one to select a property sheet
one to edit a property
one to change a property sheet
1. edit_properties
dtml-var standard_html_header
centerbPlease Pick A Property Category/b/center
table align="center"
form action="edit_propertyCategory" method="POST"
trtd
SELECT name="PropertyCategory"
dtml-in "propertysheets.items()"
OPTION value="dtml-var sequence-key"dtml-var
sequence-key/OPTION
/dtml-in
/SELECT
/tr/td
trtdINPUT TYPE="SUBMIT" value="Edit Properties"/td/tr
/form
/table
dtml-var standard_html_footer
2. edit_PropertyCategory
dtml-var standard_html_header
dtml-if "REQUEST.has_key('PropertyCategory')"
dtml-in "propertysheets.items()"
dtml-let y=sequence-key
dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item
table border="1" align="center" cellspacing="0" cellpadding="4"
trth colspan="2" align="center"Edit dtml-var y
Properties/th/tr
form action="edit_propertiesChange" method="POST"
dtml-in "x.propertyItems()"
trtd
dtml-var sequence-key
/tdtd
input type="text" name="dtml-var sequence-key" value="dtml-var
sequence-item"
/td/tr
/dtml-in
trtd colspan="2" align="center"input type="SUBMIT" value="Change
Properties"/td/tr
input type=hidden name="PropertyCategory" value="dtml-var
PropertyCategory"
/form
/table
/dtml-let
/dtml-if
/dtml-let
/dtml-in
dtml-else
You have reached this page in error
/dtml-if
dtml-var standard_html_footer
3. edit_propertiesChange
dtml-var standard_html_header
dtml-if "REQUEST.has_key('PropertyCategory')"
dtml-in "propertysheets.items()"
dtml-let y=sequence-key
dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item
dtml-call "x.manage_changeProperties(REQUEST)"
dtml-var PropertyCategory Properties Changedbr
a href="dtml-var URL1"Back To Object/abr
a href="dtml-var URL2"Back To Container/a
/dtml-let
/dtml-if
/dtml-let
/dtml-in
dtml-else
You have reached this page in error
/dtml-if
dtml-var standard_html_footer
___
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] two-phase-commit question
ZOPE_HOME/lib/python/Shared/DC/ZRDB/TM.py Glancing over the Transaction TM mixin class... i noticed a line commit=tpc_abort=tpc_begin i can understand tpc_begin=commit, but the abort seems strange. if an abort happens in the two phase commit the equality doesn't make sense to me. whats going on here? Is this meant to be overidden? TIA Kapil ___ 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] ZModules - A loaded gun
i wrote up an interface to allow for module registration in the dtml
namespace, _
its got major caveats, but it might be useful for some.
at the moments its just a stop gap till the new python methods come
along. at the moment if just allows for people to write more code in
dtml:( or ttw python methods.
it might be useful to allow ttw developers access to some modules
without allowing them use of XXXpython_methods since the configuration
file that defines the imported modules resides on the FS.
an example use
dtml-let y="_.poplib.POP3('mail.earthlink.net')"
dtml-var "y.welcome"
dtml-var "y.user('kthangavelu')"
dtml-var "y.pass_('ipc9@longbeach')"
dtml-var "y.stat()"
/dtml-let
and the response
+OK EarthLink POP server (version: EL_3_10 ) at pop04.earthlink.net.
[EMAIL PROTECTED]
+OK Password required for kthangavelu.
+OK kthangavelu has 0 messages (0 octets).
(0, 0)
personally i thinks it better to just pass the module off to a python
method
and let it do the work. real coding in dtml is heinous, maybe even a
crime against humanity.
how it works.
it reads a module configuration from the FS. fmt is currently
module_name: class_name, class_name
it tries to import the module and than place the module in the namespace
dict.
- usual python discovery rules apply (python_path, curdir)
it sets the magic key __allow__access_to_unprotected_subobjects=1 on all
imported modules.
it allows you to define classes in modules those you want to interact
with. defining those classes allows you to interact meaningfully with
instances otherwise zope's security policy will bump you because the
container doesn't define proper permissions or the magic key.
caveats:
it hasn't had much testing, i did it as proof of concept and because i
had an itch.
you can't accces any attributes of any object that doesn't define
__allow__access_to_unprotected_subobjects=1
an example where this is a pain, are getting filehandles back from
libraries,
like urllib.urlopen (note. urllib is not ts).
BE VERY VERY WARY OF THREAD SAFETY ISSUES
it might be very much like holding a loaded gun to your server;)
possible improvements:
allow for nested modules classes
?
if people think this is useful enough, i'll package it up as a product.
installation.
create a directory in your products folder (mines called ZModules)
drop in the attached file.
write a configuration file
restart zope
sample config file.
poplib:POP3
mimetypes
Cheers
Kapil
# DISTRIBUTED UNDER THE ZPL
# Author [EMAIL PROTECTED]
# made for zope, www.zope.org
import App
import App.Common
import Globals
import os
from DocumentTemplate import DT_Util
from DocumentTemplate.DT_Util import d
from string import strip,split,replace
config_path=os.path.join(App.Common.package_home(globals()), 'zmodules.config')
fh = open(config_path)
modules_list=fh.readlines()
#print 'read config file'
counter = 0
for module in modules_list:
module = strip(module)
module = replace(module, '\012', '')
if len(module) = 1:
continue
module_config = split(module, ':')
if len(module_config) 1:
classes = split(module_config[1], ',')
else : classes = []
module = strip(module_config[0])
module_name = module[:]
try:
exec('import %s'%(module))
except:
continue
loaded_mod = eval(module)
s_classes = classes[:]
for class_name in classes:
class_name=strip(class_name)
if len(class_name) == 0: continue
try:
getattr(loaded_mod,
class_name).__allow_access_to_unprotected_subobjects__=1
except:
s_classes.pop(s.index(s_classes))
d[module_name] = loaded_mod
loaded_mod.__allow_access_to_unprotected_subobjects__=1
print 'success: loaded module %s and classes %s'%(module_name, s_classes)
Re: [Zope-dev] RFC: page contracts
Petru Paler wrote: Hi eveyone. While playing around with the development version of ACS (ArsDigita Community System), I noticed a very nice feature they introduced, namely page contracts. I've been working with the ACS quite a bit lately (day-job:). its a nice a system that offers a lot utility functions that would be nice to see ported over to zope. most of its value lies in its data models. zope and the acs have vastly different semantic models. i honestly see a lot of the acs work as hacks around some of the problems of the programming paradigms enforced by aolserver, that have little meaning in a system as expressive and customizable as zopes(object publishing v. page publishing sql apps). with regards to the page_contract. IMO its def. useful from the standpoint of documentation and error checking for your variables. implementing this as a folder of utility methods and simply calling them from any doc that acquires from them, passing in the request and optional args (props of doc?a nd this()?), achieves the needed effect without much effort, and offering quite a bit by way of customization. its also possible to do this as a python mixin class for objects. but it would require a alot more work to do it transparently to the developer. Kapil In ACS, this means that every tcl page starts with a call to ad_page_contract. In the parameters passed, you specify: - general page documentation (what it does) - author(s) - creation date (not needed for Zope since we have bobobase_modification_time) - CVS ID (not quite applicable for Zope (yet?)) - the expected input variables (from forms) along with their default values (where applicable) and types (having a couple of types like "integer" and "string" predefined and an easy-to-use plugin system to add custom types) - an optional validation block in which you can check the input data ranges and validity (you can also make validation rules depend on each other so if one fails, the rules which depend on it aren't tried) - an optional custom error messages section (to use when one of the required input variables is not there or does not match the format, or when a validation block fails). If you don't provide this some reasonable defaults are provided. IMHO, such a feature would be very useful for Zope too. I find myself quite often doing input validation and error handling in DTML, which is (to say the least) painful. I would be interested to give a try at implementing this, but before starting I wanted to hear community's opinion on: - whether this would be useful - how this should be aproached (the two possibilities I have in mind until now are either a separate manage tab for the page contract, and there a HTML-based interface for building it, either a dtml-contract tag which surrounds the page contract (written in python probably) and placed at the top of DTML documents/methods). -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 ___ 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 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] New version of BTreeFolder
Kapil Thangavelu wrote: Shane Hathaway wrote: BTW has anyone done any semi-formal speed tests? It's rumored that a custom getattr in Python can cause a bit of a slowdown. We could write a custom getattr in C to solve the problem. But we don't want to do any premature optimization. Shane I'll work on some tests. Kapil semi-formal test i ran some basic tests comparing a btree folder against a folder. i'm not sure about my testing methodology but here are the results. the test code is at the end of this email. the first pair of numbers is a timed creation test for size xxx of DTML Documents. the second pair of numbers is a timed test for len(objectIds()) the third pair of numbers is a timed test for attribute access with a call to int(dtmldoc.title_or_id()) # all the ids are stringed numbers my test box is running mandrake 7.1 with 512 M ram, dual proc celerons 550s (oc'd) some quick conclusions. the btree folder is slower on average for creation by anywhere from 15-25% andt btree's __getattr is on average almost twice as slow as the folder's getattr. order folder followed by btreefolder for size 100 0.0974419116974 :::0.126843929291 0.000378012657166 :::0.000354051589966 0.0101770162582 :::0.0186030864716 for size 100 0.0978569984436 :::0.125252962112 0.000376105308533 :::0.000353932380676 0.0101470947266 :::0.0185579061508 for size 500 0.52112698555 :::0.657492995262 0.00154399871826 :::0.00154197216034 0.0524510145187 :::0.0956329107285 for size 500 0.53660595417 :::0.714686989784 0.00154197216034 :::0.00157594680786 0.0532569885254 :::0.100463986397 for size 1000 1.11411702633 :::1.4010369 0.00302505493164 :::0.00306105613708 0.105547070503 :::0.193196058273 for size 1000 1.12388503551 :::1.58762395382 0.00370097160339 :::0.00381696224213 0.106634020805 :::0.194367051125 for size 2000 2.60056698322 :::3.20675897598 0.007483959198 :::0.00741696357727 0.216197967529 :::0.396993994713 for size 2000 2.64964604378 :::3.26421093941 0.0074850320816 :::0.00761103630066 0.214147925377 :::0.40997505188 for size 5000 9.50434195995 :::11.0002789497 0.0184400081635 :::0.018413901329 0.533676981926 :::0.997251987457 just to be fair i reversed the positions and did a second set of runs with only 1 run per size as the results were consistent with the first set. for size 100 0.128319978714 :::0.10124707222 0.000413060188293 :::0.000383019447327 0.018816113472 :::0.0104240179062 for size 100 0.12813603878 :::0.101204037666 0.00040602684021 :::0.000380039215088 0.0188159942627 :::0.0105849504471 for size 500 0.681550979614 :::0.546862006187 0.00152194499969 :::0.00160706043243 0.0983099937439 :::0.0540620088577 for size 1000 1.47808301449 :::1.17385303974 0.00308799743652 :::0.00319290161133 0.197283029556 :::0.108732938766 for size 5000 11.1204429865 :::9.15097498894 0.015163064003 :::0.0150960683823 1.00954806805 :::0.535046935081 Despite this evidence. at size 5000, looking at the btreefolder contents in the management screen was near instaneous while the folder took almost a minute. based on the above evidence though that has more to do with the interface than the underlying speed of the folder methods. night. Kapil test code to follow. external method import time import os import Products.BTreeFolder def btest(self, REQUEST, =None): ''' ''' if not : =100 results = [] bf = Products.BTreeFolder.BTreeFolder.BTreeFolder() bf.id = 'btree_test_b' self._setObject(bf.id, bf) id = 'btree_test_f' rf = self.manage_addFolder(id) # creation test for completeness stime = time.time() for num in xrange(): self.btree_test_b.manage_addDTMLDocument(str(num)) etime = time.time() result = etime-stime #self.get_transaction().commit() stime = time.time() for num in xrange(): self.btree_test_f.manage_addDTMLDocument(str(num)) etime = time.time() results.append(result, etime-stime) # access test stime = time.time() len(self.btree_test_b.objectIds()) etime = time.time() result = etime-stime stime = time.time() len(self.btree_test_f.objectIds()) etime = time.time() results.append(result, etime-stime) # iteration test stime = time.time() for oid, item in self.btree_test_b.objectItems(): int(item.title_or_id()) etime = time.time() result=etime-stime stime = time.time() for oid, item in self.btree_test_f.objectItems(): int(item.title_or_id()) etime = time.time() results.append(result, etime-stime) return results ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts
Re: [Zope-dev] New version of BTreeFolder
Shane Hathaway wrote: Hi gang, This version just fixes a bug with the folder contents tab on Windows. For some reason, on Windows 95 (and perhaps other platforms) the Python interpreter behaves differently enough that if you use a class attribute from a different module and put it in your own class, you may in fact be modifying its global context. It's probably a bug in Python. As a workaround, this version of BTreeFolders doesn't have the "details" tab anymore. http://www.zope.org/Members/hathawsh/BTreeFolder/BTreeFolder-0.1.1.tar.gz BTW has anyone done any semi-formal speed tests? It's rumored that a custom getattr in Python can cause a bit of a slowdown. We could write a custom getattr in C to solve the problem. But we don't want to do any premature optimization. Shane I'll work on some tests. Kapil ___ 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] Caching problems
Bob Pepin wrote: On Wed, Aug 16, 2000 at 05:31:29PM +0100, Carlos Neves wrote: You directly change a nonpersistence participant object. As stated in http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html : [...] but mainly... RTFM ;-) Well, thanks, but too bad the only FM I've been able to find about Zope are those .py files in lib/python/... I spent a whole day looking for documentation on ZODB internals on zope.org and zdp.zope.org, without being able to find anything... how about adding that paper to the search engine on zope.org? Is there more documentation like that one out there? a couple actually, not located so that you can find them but they exist jim fulton's paper from the ipc8 (python conference) is excellent reading material. http://www.zope.org/Members/jim/Info/IPC8/ZODB3News also the uml models http://www.zope.org/Documentation/Developer/Models/ZODB/ and another excellent paper by andrew kuchling on zodb and ZEO http://starship.python.net/crew/amk/python/writing/zodb-zeo.html there is also a how-to... Cheers Kapil ___ 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] Online Docs
I've been playing around with the ACS a bit lately. Its got one feature which i would desparately like to see in zope. namely that every ACS server is self documenting with regards to all of its methods. to see it in an action check out http://www.arsdigita.com/doc/procs this documentation is generated on startup of the server for all available functions which make a call to a function proc_doc. i looked at the existing python code auto documentors and the one i saw that looked the best was http://www.lfw.org/python (at the bottom of the page) for documenting live objects. it could use some modifiying to generate zope objects which would get cataloged and also to include a functions/modules source. does anyone think that this would be a good resource to have in zope. searchable docs for developers on their servers of all the Zope Internal Python Code and the Code for all the installed Products? Kapil ___ 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] Making ZClasses AutoForm Generate
I was reading over on linuxworld about some of Nick's complaints against zope. one of them was the lack of ZClasses being able to autogenerate forms for their property sheets. i wrote up some dtml methods which do just that, see http://lists.zope.org/pipermail/zope/2000-July/029325.html (i would have cross-posted but i was expecting a spanish inquisition:) any DC people want to comment about folding something akin to this into Zope's ZClass Machinery. Cheers Kapil ___ 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] Building A MailMan Search Interface
I've come across an itch. I'm tired of having to go through the mailing archives to find what i need. The search interface at egroups, is a bit slow and cumbersome. The one at ntlpd is much nicer, but i'd like to have my own so i can point an archiver/search interface at any mailman mailing list. So i decided i'd like to make a generic mailman search interface in zope. i've got a cronable retrieval script working that grabs archives. the next step is pretty crucial and i thought i'd ask around for advice. My question than becomes one of storage and parsing. I'm looking for suggestions on how to do this in an efficient and speedy manner. I'm willing to use linux/nix specific stuff if it helps performance. options: first question that applies to most of these approaches is whether to store mails an individual items or in default format of the text archive. flat file: this gives me a couple of parsing/searching options. like using grep or the c regexp library or the camel library (from helix code's evolution) any other options for this format? downside, this introduces some minor hurdles with presentation. zodb - btree folder for parsing/indexing this basically forces me to use zcatalog, which i don't think will scale to the amount of raw text without lotsa of ram. i could be wrong (i haven't gone through the Catalog code), but this is my working understanding of it. if i store the emails as archives i could probably whip up a reasonably speedy external method that would search through them. one benefit will be the ease of the presentation logic. but this is secondary to a speedy system. rdbms (probably postgres - maybe mysql) i'd prefer postgres since i'll probably be doing some other work with it. but %like% is probably one of the most expensive operations you can use on a db and its pretty limited in syntax. if i had a spare oracle system than i'd drop it in a heartbeat and use Intertext Media jaunx for searching. But i'd hate to tie this to a very expensive closed system. mysql seems to excel at speed (perhaps because it was designed for it:) but again the limitations of sql search syntax pop up. if anyone knows of any good ways to search through text in a db i'd love to hear about em. right now, i'm leaning slightly towards a flat file storage, but i'd love to hear some suggestions. Cheers Kapil ___ 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 )
