Re: [Zope-dev] We need to change how code ownership works.
On 20.08.2012 12:10, Charlie Clark wrote: Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro rege...@gmail.com: Such as? As previously noted: the TC's in particular the indemnification clause. Plus, the usual when dealing with an apparently free service provided by a company beholden to VC's. There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself. https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... even the linux kernel guys seem to prefer the benefits of github. https://github.com/torvalds/linux still, all your concerns are reasonable, but the claimed implications should stay lifelike. Robert Charlie -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
On 20.08.2012 12:39, Charlie Clark wrote: Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter r...@squarewave.at: There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself. ah, the common cold defence: everyone has it so it must be good. no, just a manner of chance. and even if, git is not proprietary. https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. This is pure speculation, or are you privy to board decisions at Github. see above, git is not proprietary. nobody is trapped inside github at all if nasty things happen. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... This irrelevant in the context of ownership and copyright. you came up with concerns against VC's. So in which context was this meant then? -Robert Charlie -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
On 20.08.2012 12:49, Wichert Akkerman wrote: On 08/20/2012 12:39 PM, Charlie Clark wrote: Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter r...@squarewave.at: even the linux kernel guys seem to prefer the benefits of github. https://github.com/torvalds/linux Yes, promotional materials would have nothing to do with the commercial nature of the service. Not that I'm against a commercial service provider. In this case also untrue as far as I know: Linus only setup a mirror on github to have some way to publish a git tree after the kernel.org comprise. He was also very explicit about not willing to use any github features. See my presious mail, i already revised this. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
On 20.08.2012 12:39, Charlie Clark wrote: I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me. i agree. but even here i wonder whats the difference if someone claims copyright on code which was committed at github vs. code which was committed somewhere else. Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this? No. -Robert Charlie -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 19.08.2012 10:30, Jens Vagelpohl wrote: On Aug 19, 2012, at 10:17 , Lennart Regebro rege...@gmail.com wrote: And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor? Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin. In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal I am giving you ownership of this code? I am not sure. GitHub makes this pulling in of outside code even easier. I'm afraid it will become even harder to really maintain this chain of custody. I just wonder why this works then for other projects like plone or pyramid which basically follows similar rules as the ZF with a signed contributor agreement required in order to make core contributions. http://plone.org/foundation/contributors-agreement/agreement.pdf/view https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt btw - pyramid seem to have a very pragmatic approach for the signing process ;) Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW. For me the discussion sounds a little like a general denial against github using the legal story as rationale. robert jens ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 19.08.2012 12:16, Jens Vagelpohl wrote: On Aug 19, 2012, at 10:55 , Robert Niederreiter r...@squarewave.at wrote: https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt btw - pyramid seem to have a very pragmatic approach for the signing process ;) An approach I doubt will hold up in a court of law. We require and have wet signatures, which makes me feel a lot more on the safe side. Thats fine to everyone i think. Referring to github this would require to give write access only to people who have signed the agreement. Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW. Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor. How does this 'clear gesture' from the non-contributor look like right now? A patch attached to an email or a bug report? As Lennard pointed out, how does this differ from a pull request attached to a repository? For me the discussion sounds a little like a general denial against github using the legal story as rationale. Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. Also perfectly fine. Maybe it's anyway a good idea to find a process enabling contributors going to github with ZF code. robert jens ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
On 19.08.2012 13:01, Lennart Regebro wrote: On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl j...@dataflake.org wrote: On Aug 19, 2012, at 10:17 , Lennart Regebro rege...@gmail.com wrote: And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor? Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin. In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal I am giving you ownership of this code? I am not sure. GitHub makes this pulling in of outside code even easier. I'm afraid it will become even harder to really maintain this chain of custody. This is then, IMO a problem that we should fix. What you are in fact saying is that the current system are violating people's copyright everytime we merge a non-contributors patch. It is unfeasible to not merge peoples patches, and I think it is also a big problem that the way the ownership of the code works now inhibits the increased simplicity of making and merging fixes for non-core contributors. In other words, we have had an ownership situation which is terrible, and nobody seems to have realized this until now. Well, now we know. As such, the discussion must now shift from don't do this to how do we do this. Poeple want to contribute and we should not say don't do that, we have to figure out *how* to make it possible to do that, and pretty pronto as well. Would it stand the law if there would be a written statement inside the relevant projects stating out that the ownership of code changes as soon as an outside patch gets applied? robert //Lennart ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Referring to same interface using zope.schema.Object
Hi, On 22.07.2011 12:59, Joe Steeve wrote: Hello, I am trying to construct an object tree. Take a look at http://pypi.python.org/pypi/node This is probably what you need. Regards, Robert Every node in the tree is of the same type. I am trying to achieve something like: class INode(Interface): parent = Object( title=uParent node, schema=INode ) children = List( title=u'Child nodes', value_type=Object(schema=INode) ) The above fails with NameError: name 'INode' is not defined. Any clues as to how to solve this? Regards, Joe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Configurable Blob Permissions ZODB
Hi, Refering to this bug report https://bugs.launchpad.net/zodb/+bug/683751 And this usecases http://stackoverflow.com/questions/6168566/collective-xsendfile-zodb-blobs-and-unix-file-permissions It would be great if create mode of blobs would be configurable in ZODB directly. For UNIX Systems there could be 2 flags for folder creation mode and blob file permissions, i.e. BLOB_FOLDER_MODE = 750 BLOB_FILE_PERMISSIONS = stat.S_IRUSR | stat.S_IRGRP which are used then at the appropriate places. See here: http://pastebin.com/wNLYyXvw I don't know how this refers to NTFS, though. Further this configuration flags should be available in ZOPE and ZEO Server configuration files. Any doubts, suggestions, other ideas? Regards, Robert -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Configurable Blob Permissions ZODB
Am Freitag, den 17.06.2011, 08:06 -0400 schrieb Jim Fulton: Any doubts, suggestions, other ideas? -1 for a new configuration option. I would rather just have write permission *only* removed from committed blob files. Read permissions should be controlled by existing mechanisms such as umask. So changing the creation mode for folders to 755 and for blobs to 444 would be the solution then. right? Has this a chance to get into the next ZODB release? Robert Jim -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zc.recipe.cmmi sticked to version 1.5.0b1 of zc.buildout dependency
Hi Folks, Why does recent zc.recipe.cmmi sticks hardcoded to version 1.5.0b1 of zc.buildout in setup.py? Regards Robert ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hi, Am Samstag, den 17.01.2009, 11:36 + schrieb Martin Aspeli: Dieter Maurer wrote: Christian Theune wrote at 2009-1-16 09:06 +0100: I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder about it. IMHO this implements an anti-pattern in an official way without a warning that this needs to be handled with care. IMHO, it is not an anti-pattern: We have a global site why should we not have a global request? When Zope is used as a Web Application Server, it is quite natural to expect a request. +1 +1 as well However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. Isn't there always the risk that people design software the wrong way? This is a documentation issue, though. Martin Robert ___ 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.browser?
Hi, Am Freitag, den 12.12.2008, 05:06 +0100 schrieb Roger Ineichen: ... Let's keep this pending and discuss at a later time again. ok. please let me know when there's cleard space for features, regards, robert Regards Roger Ineichen ___ 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.browser?
Hi, Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick: On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) regards, robert ___ 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.browser?
Hi, Am Donnerstag, den 11.12.2008, 17:13 +0100 schrieb Roger Ineichen: I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form) I didn't see any other (browser) interface which should go to this package because of real dependency problems yet. But sure if you see something which can solve problems, feel free to move interfaces, dependency less components or helper methods to this package. We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerstone/browser/interfaces.py might be a candidate for this or such a component. We use it most of the time as mixin for browser views, content providers, menu items and everything else which has to deal with application state data, urls and queries. For IRequestMixin the implementation is almost finished (one function and some testing left - see base.py and base.txt if you're interested in), and for the pointed usecases there are convenience implementations. It would be great to see this or something like this in zope.browser package, dealing with request data and url's is almost every day's business and always more code than i could be. regards, robert I think everything which goes to zope.browser must take very care on dependencies. I guess one important rule should be, zope.browser should depend on anything. Probably an exception whould be zope.schema, zope.messageid. Any other ideas? Regards Roger Ineichen Regards. Martijn ___ 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 ) ___ 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.browser?
Am Donnerstag, den 11.12.2008, 18:18 +0100 schrieb Martijn Faassen: Hi there, Robert Niederreiter wrote: [snip] We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerstone/browser/interfaces.py might be a candidate for this or such a component. While this is certainly an interesting package, I think the idea behind zope.browser is to keep dependencies to an absolute minimum. I'm not sure I see the point of just putting the *interface* IRequestMixin in zope.browser, and the implementation would almost certainly pull in more dependencies, right? It would be possible to strip the implementation dependencies down to zope.interface and zope.component if IAbsoluteUrl (iirc) is moved as well and the ICookiePrefix default implementation returns something static. (by the way, an interface called 'Mixin'? Isn't the mixin nature a property of a class, not an interface?) Yes ;), the naming is not the best choice. The intention was to hint the reader how an implementation of this interface is supposed to be used. I think we should be careful not to introduce more functionality into zope.browser right now that isn't moved from some other zope.* package. The goal after all, as I understand it, is to reduce installation dependencies. you queried ideas. right? regards, robert Regards, Martijn ___ 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 ) -- Robert Niederreiter IT-Architecture Engineering Aflingerstraße 7 A-6176 Völs +43 699 160 20 192 +43 512 89 00 77 Squarewave Computing WEB APPLICATIONS, ZOPE, PLONE, HOSTING BlueDynamics Allianceproduction: concept, development, design http://squarewave.at consulting: analysis, coaching, training http://bluedynamics.com management: projects, process, community ___ 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] Request for comments: Devilstick persistence/storage
Hi, no news seem to be good news, let's do it this way then? robert Am Donnerstag, den 13.11.2008, 15:05 + schrieb Jens W. Klein: I would like to request comments on our idea how to use different storages for our new model-driven approch with the name Devilstick. You dont need to know devilstick or its ideas in depth to give valuable input. More it would helps us to get input from people knowing zopes persistency layer in depth. Devilstick is model driven framework to describe and manage data inside and outside ZODB. some more information at http://devilstickproject.net At Blackforest sprint in august we researched how the goal to support different storages than ZODB can be achieved. After first thinking about an own layer we got there the idea of using the usal persistence and transaction API of zope. IIRC it was a result of a conversation between Florian Friesdorf and Roger Ineichen and probably others. Today is the last day of Bolzano sprint. We researched a lot how it currently works with ZODB and discussed about how to use all this framework for devilstick. Our outcome is a document describing what we found and how we want to use all this. It follows here. for the devilstick-team Jens Klein = --- Introduction to Devilstick Storages --- This document describes the future. One of Devilsticks power is to support different storages than ZODB easily. The storage layer uses 100% zopes persistency implementation. At some entry point we enter the model driven world of devilstick: We hit 'Cage'. The Cage itself is not a data-access-object (DAO). But its the bridge to the otherstorage layer. Inside Devilstick DAOs are still persistent objects. They may still live in ZODB. But they can live complete outside if it is needed. They may live in SQL-databases, in LDAP, filesystem or fetched over a webservice. For more about DAOs and its API please read API.txt. Excursus: Zopes Persistence Framework - Classic zope objects are derived from 'persistence.Persistent'. Those objects are tracking themselfes for modifications. Once a modification is detected it joins it's data-manager to the current transaction-manager. All this happens in zope fully transparent. The data-manager is the key to the storage layer. Zope is designed to use different data-managers. Datamanagers are described well in 'transaction.interfaces.IDataManager'. They care about storing all data in a 2-phase commit. There is usally one data-manager for all modified object of one database. Transaction-manager collects all datamanagers (which are called resources inside the transaction-manager) with modifications. Once the transaction is committed the 2-phase commit is started: 1st 'tpc_begin' is called on each data-manager, 2nd the 'commit' is called for each, then 'tpc_vote' and finally 'tpc_finish'. After creation of a persistent object it has an attribute called '_p_jar' set to 'None'. _p_jar gets a datamanager set - almost magically - after it was added to a container. The datamanager taken there is copied over from the containers _p_jar attribute. Container and new object are marked as modifed and the datamanager joins the transaction. On commit both are written to the database. Devilstick persistency -- To provide other storages we alreay have a powerful framework: the persistent api and transaction api. Devilstick uses both. To use a different storage simply a new data-manager is needed. Anyway, for several uses-cases its fine to stay in the ZODB. Such a alternative datamanager might work different inside than the current ZODB one. Since we deal with SQL or LDAP we want to update a database with one query for several objects involved. So on commit we may need to look at the modified objects and build one sql-query from a bunch of modifications. Frameworks like SQLAlchemy may help us here for SQL and others are probably available for different use-cases. Entry-Points: Cages --- We need one point where the datamanager is switched to a different storage.A model is assigned and there the world of generic DAOs is entered. This entry point is called 'Cage'. A cage is still persistent in the ZODB and uses the zopes default data-manager. A cage has the root container DAO (which is a generic molecule DAO) set as an attribute. Here some example code how it looks like: cage = Cage() cage._p_jar None somezodbcontainer._p_jar Connection at ... somezodbcontainer['data'] = cage cage._p_jar Connection at ... cage._root None cage.model = 'examplemodel' cage._root Molecule
Re: [Zope-dev] configuring global utilities in zcml
Hi, Am Dienstag, den 05.08.2008, 11:43 +0100 schrieb Chris Withers: Nikolay Kim wrote: I'm aware of this but it kind of defeats the idea of seperating code and configuration... So, other ideas? create new zcml directive. That seems pretty heavyweight :-/ disagree, that sounds quite zopeish robert Chris ___ 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 )
