Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/8/07, David Pratt [EMAIL PROTECTED] wrote: Hi Dieter. Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. It has a community of pure zope 3 developers (that I don't believe the suggestion of folding the lists together adequately considers). Again, these lists are about the development of, not development with. There are indeed some people developing only Zope3 but not involved in Zope2. I don't think they are very many. There are none involved in Zope 2 that are not involved in Zope 3. More so, I get the impression that the unstated goal here is to assimilate zope 3 into a different notion of 'zope' It's not unstated, although admittedly, it is in my opinion off topic for the discussion. that would further obfuscate it as a framework Nope. (under the influence of zope2). Nope. Zope 3 stands on its own as a framework and I sure hope I am wrong about how I have been interpreting the dialog. You are indeed, yes. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
On 10/8/07, Roger Ineichen [EMAIL PROTECTED] wrote: Hi Lennart -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Lennart Regebro [...] Again, these lists are about the development of, not development with. Can you explain why do you think this makes a difference? Because developing WITH Zope2 and Zope 3 are very different. The development OF Zope 2 and Zope 3 are not, sincem as mentioned, the development OF Zope 2 is almost exclusively about getting more Zope 3 into Zope 2. The differences in community that is taken as a reason for keeping the lists separate simply do not exist anymore. There are no separate Zope 2 developers anymore. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
On 10/8/07, Roger Ineichen [EMAIL PROTECTED] wrote: I think your mail also means, we can't avoid to have Zope 2 topics on the zope3-dev list because Zope 2 is going to move to Zope 3 and we have to exchange information. Doesn't matter how the list is called. Exactly. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 releases?
On 10/6/07, Jim Fulton [EMAIL PROTECTED] wrote: - We need to decide what a Zope 3 release is (or maybe multiple flavors). I favor copying the linux experiences, but have an open mind. I'm not sure what you mean with that, but for me, a known good set, or what you call it, plus a buildout that uses this, would be enough for a Zope 3.4 release. If we easily can build the old standard downloadable tgz as well, then fine, but it's not necessary. - We need a *realistic* (especially wrt available resources) process for managing releases. There are 2 aspects of this. We shouldn't make plans for which there aren't enough resources. We also shouldn't plan significant tasks that people won't care enough to work on. I think the classic Zope 3.4 release is a good example of a large effort that really wouldn't benefit many people, if any. Do you have a sort explanation on what is the missing resource? Is it, as it was for 3.3, lack of people-hours with knowledge in fixing the last bugs? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On 10/7/07, Brandon Craig Rhodes [EMAIL PROTECTED] wrote: There is danger here. Many in the industry consider Linux to be an absolute disaster - because after you develop an application on one distribution, you can spend months trying to support customers who attempt to run it on other distributions! In the wider Unix world things are even worse. Tools like autoconf absorb months and years of developer effort to simply get products to compile everywhere. Right, but the problem I think is that people say that applications run on Linux, and also spend time to make them do so, and that needs a lot of time spent. I think that an application running on a pure Zope 3 would run also on Grok, but it would be entirely possible to make another application that for example doesn't use the ZODB at all, but still uses the rest of the Zope3 ecosystem. And an application running on Zope 3.3, would not run on such a distribution. So if we make Zope3 less of an application and more of a platform/environment/ecosystem, we should probably not say that anything runs on Zope3, and that would then solve that problem. Applications would *run on* Grok, but *use* zope 3. But I suspect that we then end up with your Python model, right? :-) Now, it sounds like Zope is about to stop being like Python and start being like the current Wild West of Linux distributions. If I want to write a WebWidget in the future, and want it to work with Grok, and Zope on Wheels, and ZopeSprockets, and whatever other frameworks might come along, then I will be faced with situations like Well, Grok has already moved up to zope.security 3.7, which means I can use key cards natively! Hmm, but the other frameworks have not upgraded past 3.6; I will have to special-case key-cards for them. On the other hand, Grok stayed with zope.templates 3.5 because they piled so many extensions on top that they didn't get time to redevelop them for 3.6, so I'm going to have to fake push-masking in Grok... Y, I see your point. But is this avoidable at all? Even with more fixed sets of versions we have this exact problem already today. I would like to use utilities, but Plone 2.5 is still on Zope 2.9 which has a slightly different utility implementation than Plone 3, so I'm going to have to specialcase for that, and at the same time I'd like to use this under Grok which has moved on to zope 3.4... and so on. I think that with the granular versions we get with eggs, it's in fact gonna be *easier* to avoid this stuff, because I could in my application update to a newer version of the module I need, and it wouldn't actually break anything except in those cases where the module breaks backwards compatibility, which isn't supposed to happen, except in some extreme circumstances nowadays. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/6/07, David Pratt [EMAIL PROTECTED] wrote: I agree with you Roger. I want things to stay as they are for the same reasons. I have great respect for Zope 2 developers however there there are two development paradigms at play that are fundamentally incompatible despite the inclusion of component architecture in Zope 2. Sure, but this is the lists for development *of* not development *with* and development *of* Zope2 is nowadays almost about getting in Zope 3-technologies into Zope2 :-) The zope (for usage and development with Zope2) and zope3-users (which is development with Zope3) should not be merged, I totally agree with that. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/6/07, Roger Ineichen [EMAIL PROTECTED] wrote: You are using 7 times the term Zope2 and 9 times Zope 3 and also Plone 3.0 in this small text. Can you try to describe this without 2 or 3 in Zope *? I guess not, right? Now you are being silly. :-) He was writing a text about how small the difference was between Zope2 and Zope3 developer. How would he do that without using those words, so you suggest? You also use the term Plone 3.0 which you implie that we know that you mean the Plone which uses Zope 3 components. No, he explicitly says that Plone 3.0 has a heavy use of Zope 3 components. That is not an implication. You are respecting the postifx 3.0 in the Plone world but not for Zope? why? Nobody in the plone world is taking about Plone 3 developers and Plone 2 developers. I'm a little confused and don't understand why you are lobbing for such a renaming and at the same time you are using this terms so heavy. What renaming is he lobbying for? This is not about renaming anything. I think this discussion would be more constructive if you put more of your time into trying to understand what other say instead of trying to misinterpret them. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known-good-sets problem
On 10/6/07, Jim Fulton [EMAIL PROTECTED] wrote: Only people who ask for updates. Which by default is every time somebody runs a buildout, right? I think this depends on the use cases. I think most people would like to get bug fixes. The intent of such a 3.4 index would be to give people the latest 3.4 updates which should give no new features. This is intended to mimick what happens with linux package respositories. Ah, good point. But I think what Martijn is saying is that when we come with new *features* this should be made into a new page. Which would then be Zope 3.5, or something. Or did I misunderstand him? But you are right, small bugfixes, and in particular security fixes, should indeed go into the already existing page. Which means all you would need to get a security fix would be to run buildout, possibly forcing it to check for new versions if that is set to false by default. That would indeed be a very nice feature. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On 10/7/07, Martijn Faassen [EMAIL PROTECTED] wrote: While I see Brandon making good points, I also agree with this: the motivation to contribute to the Python standard library is reduced because of big bang releases. I think the main reason is that you need to wait so long to see your work in print so you can use it yourself. Yup. This may be one of the reasons behind the lack of kicking upwards, as I outlined here: http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2005_04_11_sickness_zope -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/4/07, Martin Aspeli [EMAIL PROTECTED] wrote: Also, on the subject of renaming things: Calling it zope-devel or similar may not be ideal, since people who develop with Zope (don't we all?) assume this is for any developers, not just core developers. Something like zope-general and zope-coredev may be better. +1 to also rename the dev lists to something that makes it more obvious that we are talking about development *of* zope, not *with* zope. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] I'd love to merge the zope3-dev and zope-dev lists
On 10/4/07, Jim Fulton [EMAIL PROTECTED] wrote: I though of that. Historically, the #zope channel was much chattier, which makes it hard for me to deal with. When #zope3-dev was set up, I asked that people keep the noise level down, which has made it much more useful, imo. Maybe we should keep these issues separate for now. Agreed. We need one channel that is at least vaguely hardcore and one that is not. I never get any useful answers on #zope about anything. :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/4/07, Michael R. Bernstein [EMAIL PROTECTED] wrote: This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 +1 What about retiring #zope3-dev IRC channel and only using #zope ? No. #zope is roughly the equivalent of the main zope list. There is no #zope-dev channel. Renaming #zope3-dev to #zope-dev would make sense to me though. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
On 10/3/07, Stephan Richter [EMAIL PROTECTED] wrote: I want tools! Actually, I just want one tool. 70% of the release process is repetition and that needs to be factored into a tool. This tool should have been written before the Zope trunk was blown into pieces, but it wasn't. :-( I'd recommend fixing bundleman to be able to support making eggs. Bundleman will look at the changes, suggest versions out of that, refuse to release if there are no changes set, create the tag and make the release from the tag. It's written in Python, in clear and understandable code by eminent programmer Benoit Delbosc (of funkload fame). http://tinyurl.com/ye8dsk It currently only makes releases as tgz, but adding eggs should be so hard (it's done by calling setup.py anyway if I remember correctly). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
On 10/3/07, Fred Drake [EMAIL PROTECTED] wrote: On 10/3/07, Lennart Regebro [EMAIL PROTECTED] wrote: It currently only makes releases as tgz, but adding eggs should be so hard (it's done by calling setup.py anyway if I remember correctly). tgz files are all that's needed (or wanted); there's no reason to use a .egg file. For packages that include extension modules, there are well-understood reasons to stick with a source distribution. Oh, well then maybe we don't need egg support. That's good. However, I also just realizd that bundleman currently uses the pattern of having a CHANGES file, and a HISTORY file and a VERSION file, and then massaging them and renaming them to CHANGES.txt HISTORY.txt and version.txt when used, and I think we still would need some change to support calling the files CHANGES.txt directly, or updating all the eggs might be a bit much work. (Unless we make a script for that). But it is a very good tool for making releases. It also has this nice support for releasing all the products in a whole svn-bundle, if they need releasing, which is very nice. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.securitypolicy deferred imports errors.
Roger Inechens split of zope.app.securitypolicy into zope.securitypolicy cause loads of problems, because many of the deferred imports were incorrect. I saw Stefan Richter fixed some, and I have fixed some more. First somebody that can make releases (which may or may not include me, I honestly don't know who can make releases of eggs) needs to make a new one. But we also need to avoid this stuff in the future. How is the recommended process to solve this? Some sort of unittest to make sure the deferred impoirt work? Is there an example of this somewhere? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
On 10/2/07, Roger Ineichen [EMAIL PROTECTED] wrote: In other words; Right now we only test if a egg works within their dependency. But we don't test other eggs if they work with the egg we develop. Well, first of all we need tests in the modules that the deferred import works. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On 9/29/07, Jim Fulton [EMAIL PROTECTED] wrote: This helps in cases where you want the configuration for a package, but you don't want some of the configuration that it includes. This allowed me to trim quite a bit off of the startup time, and, more importantly, the test setup time, for a project I'm working on. Works like a charm. We tried it here at the grok sprint. Although we were only able to speed up Grok startup with 10%. Maybe we can get to 20-30% if we work more on it, but we're not sure it's worth it. http://regebro.wordpress.com/2007/10/01/neanderthal-sprint-speeding-up-the-grok-startup/ -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On 10/1/07, Jim Fulton [EMAIL PROTECTED] wrote: On Oct 1, 2007, at 11:17 AM, Jim Fulton wrote: On Oct 1, 2007, at 11:09 AM, Lennart Regebro wrote: On 9/29/07, Jim Fulton [EMAIL PROTECTED] wrote: This helps in cases where you want the configuration for a package, but you don't want some of the configuration that it includes. This allowed me to trim quite a bit off of the startup time, and, more importantly, the test setup time, for a project I'm working on. Works like a charm. We tried it here at the grok sprint. Although we were only able to speed up Grok startup with 10%. Maybe we can get to 20-30% if we work more on it, but we're not sure it's worth it. http://regebro.wordpress.com/2007/10/01/neanderthal-sprint- speeding-up-the-grok-startup/ Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Oh BTW, I ran Zope with debug logging. That way I could see what was being included. Oh, useful... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal, free views
On 9/23/07, Roger Ineichen [EMAIL PROTECTED] wrote: Such built in views means what? Optional how? And why? I mean with built in views just views which comes within a package. Such view component are located in the browser folder and built on the BrowserPage classes. I guess the term views is common for that and should be well known. You misunderstand. I did not ask for an explanation of wat views meant. I asked for what you mean with such built in views. It seem sthat you mean the views that make up the ZMI. Yes, this is what we like to do. We like to write 3rd party packages. But the problem is, this views are using templates which we don't support, e.g. use-macro, fill-slot etc. Aha, the views that exists uses a master template macro that you don't have. Also the configure.zcml file registers menu items for zmi_views and zmi_action which is does not exist in our setup. I guess it should be possible to use Zope3 without the need of zmi_views and zmi_action menu items Whih is not the case right now. See all the ftesting.zcml files in the different egg packages. Pobabbly the proposal should be simpler and propose. Get rid of zmi_views, zmi_actions, StandardMacros and hardcoded template relations in views Yes. What you want to do is to get rid of the requirement to support ZMI in your design. To be quite honest, I think the best way to do that, is to not use the main_template from the pages you do, but use another main template for your own pages, and just leave the ZMI be where it is. There might be some other solution too, but this one has the benefit of the MI views still being available if you should need them. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal, free views
On 9/23/07, Roger Ineichen [EMAIL PROTECTED] wrote: Heads up, Please review this proposal. OK. I have to admit that I don't fully understand it. This proposal describes a way to make the usage of such built in views optional. Such built in views means what? Optional how? And why? The additional component.zcml could be used to include only component related configuration whitout the view parts defined in the browser.zcml. Because the browser.zcml get's included from the configure.zcml but not from the component.zcml OK, I understand what you want to do: Start the practice of having views in one zcml and components in another, so you can include only the component one if so desired. I don't understand why, though. Right now it's not possible to use another layout pattern without to support zmi_views and zmi_action and it's menut item pattern. The views defined in all packages also require the use-macro, fill-slot pattern which is not what we allways whant. Right now there is no option to get rid of this patterns except to duplicate packages and replace existing views. That's what you will have to do anyway. Because if you don't include the views, you will have to replace them in another package. And you can override them in another package already... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What does python 3000 mean for zope?
On 9/10/07, Hermann Himmelbauer [EMAIL PROTECTED] wrote: Am Sonntag, 9. September 2007 17:34 schrieb Lennart Regebro: A bit late post, but here is my thoughts on the subject. I'm hoping that Guido will see the errors of his ways, and introduce a Python 2.7 that has more forwards compatibility than what has been promised for 2.6, so that there can be a useable overlap between Python 2.7 and 3.0. Maybe a 3.1 with some more backwards compatibility will be needed to, I don't know. I share many of your fears, but I personally don't see how Python 3 and 2 could be possibly compatible. There quite some basic changes, e.g. the format specifier (print Hello %s % World) does not exist any more, strings are unicode etc. 2.6 will already introduce some forward compatibility and the things you menation are easy to make forward compatible. All you need is a from __forward__ import print And then you can do print(Ladida) in 2.6. This goes for some of the other things too. The unicode thingy is not a problem either. Let both 2.x and 3.x support u'' and b'', but make strings default to b'' in 2.x and u'' in 3.x. To make sure it works in both versions, then just have u'' everywhere! There are some things that are not easy, but I haven't yet seen anything except for some quite advance features, that are not possible to introduce forward compatibility for. However, Guido has shown no interest in actually introducing that much forward compatibility. Note that this compatibility will still require you to change to code so it works under 3.x. But do it right, and it will still work under 2.x as well. This means that you can convert your Zope product written for Python 2.x and fix it so it works under both, in 90% of the cases, at least. I have yet to be convinced that this is impossible. My hope is that the code can be made compatible in a way, so that the resulting code of the Python 2-3 conversion is running. There would be 4 versions available, true, but the Python3 versions could be generated automatically. That's never going to work, because there are too many things that can't be converted automatically. The only way to make the conversion work is to first make sure there are almost 100% test coverage. And that is not going to happen. On 9/11/07, Martijn Faassen [EMAIL PROTECTED] wrote: When I told Guido we still have a Zope 2 and a Zope 3, he said we should avoid this situation with Python. Well, then. Then we will need more forward compatibility in 2.x. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What does python 3000 mean for zope?
A bit late post, but here is my thoughts on the subject. As it looks right now, It will be virtually impossible to write code that works under both Python 3.0 and Python 2.x. This has a huge impact on Zope, because Zope as a framework does not only have a huge codebase in itself, but an even huger codebase of third-party products. If it isn't possible to write code that works under both 2.x and 3.0, that means that all of the codebase must be moved simulatneously. Even if we made a version of Zope that works under Python 3, most third-party product would not run under Python 3. In effect, if we port Zope to Python 3, we then have *four* incompatible code bases. Zope 2 for Python 2 and Zope 2 for Python 3 and Zope 3 for Python 2 and Zope 3 for Python 3. This is not only completely unmaintainable, it's never going to happen. I can possibly see Zope 3 moving to Python 3, the Zope 3 community is still small enough and well organized and tight enough for this to work. But it has to be pointed out that any Zope 3 module that isn't also ported will be unusable. I do not see how Zope 2 will ever be ported to Python 3, because doing so would break all the thousands of third-part products out that that doesn't get ported at the same time. This of course means that Plone will never get ported to Python 3. Which in fact means that one of the most successful and biggest users of Python will never move to Python 3. And it also means that anybody that is today using Zope 3 and hoping for The plone.* modules to continue to contribute to Zope 3, will see that effort virtually die if we port Zope 3 to Python 3. I'm hoping that Guido will see the errors of his ways, and introduce a Python 2.7 that has more forwards compatibility than what has been promised for 2.6, so that there can be a useable overlap between Python 2.7 and 3.0. Maybe a 3.1 with some more backwards compatibility will be needed to, I don't know. Just my 2 cents. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. In fact, the installation process might end up being simpler: Compare: wget http://www.zope.org/whatevah/Zope.tgz tar xvfz thetgz ./configure make make install make instance directory With: easy_install zopeproject zopeproject directory cd directory bin/buildout Or something similar to that. Doesn't really look more complicated to me. :-) Sure, it uses paste and stuff, but you don't have to know about that to use it. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Jim Washington [EMAIL PROTECTED] wrote: Doesn't the published object, being a view class, have context and request as instance variables? Well, yes. But these are also available directly in the Publication.callObect() method, and neither of them are available in the IResult, typically. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Gary Poster [EMAIL PROTECTED] wrote: We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? Well, most HTML output is done by templates, which typically return unicode. I guess we can let the BrowerPublication to wrap the unicode in an object... I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Maybe. :-) But just after I pressed send I actually realized that one part of the theming is getting in viewlets therem which is quite difficult if you don't have the context, which actually again points at the Publication being the right place to do this. Or am I missing something? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re-revisiting IResult (for in-Zope pipelining)
Hi all! On 4/16/07, Gary Poster [EMAIL PROTECTED] wrote: The work that Jim Washington and David Pratt have started recently to make lxml an XHTML generator/ZPT replacement [#1]_ has really excited me. It would be *great* with in-Zope pipelines [#2]_. I'm here at the grok-sprint at EuroPython and we are looking into getting a pipeline hooked in to add theming to HTML output. [The idea of this is to add the theming, that is design, viewlets and so on, by imposing it on the HTML output, instead of including it from the template. This would open up for template independency, or even skipping templates completely for simple HTML and instead just outputting it.] We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, and also IResult seems to have to handle the encoding itself, which means we need to duplicate the encoding that is already going on in setResults. I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Tres Seaver [EMAIL PROTECTED] wrote: You can't ask upstream to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
On 3/26/07, Dieter Maurer [EMAIL PROTECTED] wrote: When IncrementalSearch does it, it works roughly as Jim described it under 1 above (although there is no need that it works the the primary key directly). Right. Unless the indexes are able to return sorted (partial results), we need to determine the results first and then sort them. And that takes time at least linear in the number of hits (to determine the sort values for the documents). OK, at least this avoids the big intermediate results when searching over several indexes. But you still have to get all of the results, and sort them before you can return the X first. I have the impression that Lucene somehow solves this with their sorting indexes, but I'm not sure, and I haven't tried to understand the code. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
On 3/25/07, Jim Fulton [EMAIL PROTECTED] wrote: On Mar 25, 2007, at 3:01 AM, Adam Groszer wrote: MF I think one of the main limitations of the current catalog (and MF hurry.query) is efficient support for sorting and batching the query MF results. The Zope 3 catalog returns all matching results, which can then MF be sorted and batched. This will stop being scalable for large MF collections. A relational database is able to do this internally, and is MF potentially able to use optimizations there. What evidence to you have to support this assertion? We did some literature search on this a few years ago and found no special trick to avoid sorting costs. I know of 2 approaches to reducing sort cost: 1. Sort your results based on the primary key and therefore, pick your primary key to match your sort results. In terms of the Zope catalog framework, the primary keys are the document IDs, which are traditionally chosen randomly. You can pick your primary keys based on a desired sort order instead. A variation on this theme is to use multiple sets of document ids, storing multiple sets of ids in each index. Of course, this approach doesn't help with something like relevance ranks. 2. Use an N-best algorithm. If N is the size of the batch and M is the corpus size, then this is O(M*ln(N)) rather than O(M*ln(M)) which is a significant improvement if N M, but still quite expensive. I don't think relational databases have any magic bullet to get around sorting costs. Sorting is expensive. In many ways, I think the sorting support in the catalog gave people a false sense of security. I don't know if relational databases typically does this internally (I don't think so). However, some search engines do it, like Lucene. And supposedly also Dieters IncrementalSearch (haven't used it yet). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Buildout configurations in a subdirectory stopped working. (Was: [Zope3-dev] Buildout default behaviour)
On 2/19/07, Christian Theune [EMAIL PROTECTED] wrote: [buildout] extends = profiles/dev.cfg and run bin/buildout. This works very well for us. It did for me too, but it has now stopped working. Line 89 in buildout.py says: data['buildout']['directory'] = os.path.dirname(config_file) This must be a recent change ( 2 weeks) because this makes buildout fail if you have the cfg files anywhere else than root. I'd like to know the rationale for this change, as I'd like to be able to have the profiles in a subdirectory. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Buildout configurations in a subdirectory stopped working. (Was: [Zope3-dev] Buildout default behaviour)
Oups, I forgot that this should go to the distutils list. Please ignore, I'll repost there. On 3/16/07, Lennart Regebro [EMAIL PROTECTED] wrote: On 2/19/07, Christian Theune [EMAIL PROTECTED] wrote: [buildout] extends = profiles/dev.cfg and run bin/buildout. This works very well for us. It did for me too, but it has now stopped working. Line 89 in buildout.py says: data['buildout']['directory'] = os.path.dirname(config_file) This must be a recent change ( 2 weeks) because this makes buildout fail if you have the cfg files anywhere else than root. I'd like to know the rationale for this change, as I'd like to be able to have the profiles in a subdirectory. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Google Summer of Code
On 3/5/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: a) mentors. It'd be great if some of the Zope core committers would volunteer to mentor a student. This doesn't mean you will definitely end up mentoring one, just show your willingness. Yeah, I could do that. b) project suggestions. I'm sure I can come up with several. Finishing the twisted integration in Zope2, for example. It only does http yet we need ftp too, and maybe more. So, I think this is a good idea. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Buildout default behaviour
On 2/20/07, Jim Fulton [EMAIL PROTECTED] wrote: That's not what I want as default behaviour. :-) Can we change this to complaining that buildout.cfg doesn't exist instead? Yes. The existing behavior was added primarily to support bootstrapping, where I still think it makes some sense. Could you report this as a bug on: https://bugs.launchpad.net/zc.buildout/+bugs Also, in the future, I'd prefer that general buildout questions be raised on the distutils-sig mailing list, http://mail.python.org/mailman/listinfo/distutils-sig (Questions about zope3-specific recipes would be best asked here.) Sure thing! -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Buildout default behaviour
I'm testing buildout, and one thing I want is to have several cfgs, one for development, one for staging and one for production. Now, calling one of the configurations buildout.cfg would make it the default. That means that if you just run bin/bildout, it will try to install that configuration. That's fine for installing, but not for updating. If you install it with -c staging.cfg, and then without -c at all, it will try to switch to the buildut.cfg configuration, which is not what you want. Now, a clever way around this ought to be to have no buildout.cfg at all, and therefore no default, right? Nope, because if you run it then, it will create an empty buildout.cfg, and then promptly go around building it. Which has the effect that everything gets UNINSTALLED! That's not what I want as default behaviour. :-) Can we change this to complaining that buildout.cfg doesn't exist instead? -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Buildout default behaviour
On 2/19/07, Christian Theune [EMAIL PROTECTED] wrote: Hi, here's the pattern that we use: - create a directory 'profiles/' in your buildout - create a file 'profiles/base.cfg' that describes all parts and their default configurations - create a file 'profiles/dev.cfg' that has the development variation and uses '[buildout] extends=base.cfg' Then we do not check in a buildout.cfg at all. We put an SVN ignore on that actually. When doing a checkout of the buildout, we run bootstrap which creates an empty buildout.cfg (and uninstalls all of the 0 parts which I don't care about). We then set the buildout.cfg to look like this: [buildout] extends = profiles/dev.cfg and run bin/buildout. This works very well for us. Good idea, thanks for the hint. That gets around the problem (even though I still propose that the default behaviour change). -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: yes, but if you register an adapter for a base class you don't have to register it for subclasses, do you? I don't know, but again you then need to either subclass or re-register for that calss, but if you register it for an interface, you can eiterh subclass or implement the interface. subclasses will pick up the same adapter. Provided that you use classes for typing your objects and not interfaces. Class and interfaces do different kinds of typing. You do both, normally. I'm not sure the proliferication (?) of marker interfaces is a big risk. But if we get many of them, it still works better than the options of magic __something__ attributes. :) but conceptually it is the same mess :-) i.e. a total lack of specification. I don't agree with that at all. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Lennart Regebro wrote: On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote: Why do you say extra ZCML registration? You need that ZCML registration whether or not you have to write the marker interface... Sure, but with the marker interface you need only one. You need one for each class, in your example, thats two. So the second one is extra. :) I think it is a mistake to use interfaces to specify what object _are_ as opposed to what they can _do_. It is better to use base classes for that. Yeah, but in this example there are no base classes available, as I understand it. So it's perfectly feasible to marl something with a marker interface to say this can be adapted to X. It is a can do marking, not an is marking, IMO. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Indeed technically yes. Practically not. I couldn't find many examples in the zope3 codebase that adapts classes. The #1 pattern is to adapt from interfaces, it appears as though there is a reason for it. Yes, and I think both you and me mentioned it, but with different wordings. If you specify it for a class, then only that class is adaptable. If you want to use the adapter for yet another class, you have to register it again. This is possible, but it's more flexible to specify the adapter for an interface, and let all adaptable classes implement that interface. This is also a matter of specifying things for what they can do, instead of for what they are, which you mentioned. I'm not sure the proliferication (?) of marker interfaces is a big risk. But if we get many of them, it still works better than the options of magic __something__ attributes. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote: I'm expecting people to say NO! very loudly, but I'm interested in the real reasons for why this is bad. Well it removes the possibility of switching out the class, which begs the question why you would have an adapter in the first place. If you have a strict one to one relationship between the class and the adapter, why not just implemetent the desired functionality directly in the class? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote: It's not one to one: adapter for=.myclasses.MyClassA provides=.interfaces.ISomething factory=.adapters.MyAdapter1 / adapter for=.myclasses.MyClassB provides=.interfaces.ISomething factory=.adapters.MyAdapter1 / adapter for=.myclasses.MyClassC provides=.interfaces.ISomething factory=.adapters.MyAdapter2 / adapter for=.myclasses.MyClassD provides=.interfaces.ISomething factory=.adapters.MyAdapter2 / Re-use of adapters without having to create or use a mixin... So instead of making a marker interface, which is two lines of code, a I'm not against your suggestion, but I'm not convinced it's actually useful. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Sorry about the premature sending, I don't know what button I pressed... Here we go again: So instead of making a marker interface, which is two lines of code, and two registrations, a total of six lines (with the imports), you have an extra ZCML registration statement, which is three lines of code. So you save three lines of code. I'm not against your suggestion, but I'm not convinced it's actually useful. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote: Why do you say extra ZCML registration? You need that ZCML registration whether or not you have to write the marker interface... Sure, but with the marker interface you need only one. You need one for each class, in your example, thats two. So the second one is extra. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Zope Configuration Egg Support
On 10/23/06, Jim Fulton [EMAIL PROTECTED] wrote: If an egg installs a package and if the package isn't a namespace package, and if the egg isn't zipped, then yes, the package mechanism will work. Ick. That's a lot of ifs... Because you then get the problem if you switch between an egg version and a non-egg version of a module... I don't know what you are getting at. Well, if you have to say egg when it's a zipped egg and package when it's a package, then you can't support both at one time, which means that to support the egg you have to use include egg=.. / and then it stops working if it's not an egg. This is basically bad, although I guess it's acceptable if these are very unusual circumstances (which seems to be what people are saying further down in this thread). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On 9/12/06, Jim Fulton [EMAIL PROTECTED] wrote: FWIW, I use the following approach: - Early in the process, I mark every real reproducable bug as blocking. In this last go around, this included a number of bugs that had been around for months or years. - Later in the process I downgraded lots of bugs because I didn't want toblock the release. Ah. Well, that procedure definitely can get improved on. :) I think it is imperative that we mark bugs according to the seriousness so that you know which bug should be worked on first. I note that the Zope3 collector has the categories medium, low, critical, 3.3 release and 3.4 alpha 1. I don't think that's a good idea, but I understand that the Zope collector has no field for planned release, and those options make sense for features. :-) Anyway, for me it's like this: A blocking/critical bug is a bug that means the system or part of the system gets unusable. It has no workarounds, and affects most users of the system. Say, PUT_factory suddenly stops working, meaning that FTP and WebDAV no longer works. A serious/medium bug is a bug that is a big problem for many users and has no workaround, or affects everybody, but has a workaround. For example, that XML import/export didn't work: Workaround, use the non XML-import/export. A minor bug is a bug that affects few users and has a workaround, or has no workaround but only is a problem in very extreme edge usercases. For example...euhm, ehhh, I can't think of one right now. (and a trivial bug is not an actual problem for anybody. Could be spelling errors or ugly design.) A bug should be assigned a category and stay there. It should not get it's category changed so not block a release, because if you can do that, well, then it wasn't blocking in the first case. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On 9/12/06, Martijn Faassen [EMAIL PROTECTED] wrote: What about a policy where we fix bugs until the release date, and then on the release date, we actually release? Any bugs that are still in it are going to go with it. I totally agree. My feeling is that the x.x.0 release this time will be at least as stable as a x.x.1 release normally, maybe even more stable. Of course, it's bad to have to release a x.x.0 release to find bugs, but not enough people outside the developer world will actually install a beta or RC for that to be realistic. Remember: If all the tests pass, it's ready for a release! :-) Also, it seems to me that slippage is worse because we slip until we slip into vacation, which makes us slip even more. I even have the feeling that people go It's xmas soon, Iäll fix it then and of course you end up sleeping through xmas and eating too much instead of programming. I know I do. :) So, I'm more for a March/September cycle for these reasons. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re: Zope 3 as a reliable platform?!?
On 9/8/06, Dario Lopez-Kästen [EMAIL PROTECTED] wrote: Lennart Regebro said the following on 09/07/2006 05:50 PM: On 9/7/06, Rocky Burt [EMAIL PROTECTED] wrote: My experience so far... after not having touched a project for over a year and than the client wanting some work done, they usually expect to have to pay to have it upgraded. Well, in any case, they SHOULD expect that. Yes, but we're not talkng about migrating from zope 2.6 to 3.3. We are talking about people experiencing issues between 3.x to 3.3 here. Zope 3.3 is not a major new release with deeply incompatible changes from 3.1, at least not if you look at the version numbers. If it was then it perhaps it should have been versioned as 3.5 or even 4.0, marking the impact on existing code obvious. For both developers and customers. I think customers expect not to pay a lot of money for migrating from 3.1 to 3.3 for instance. No matter how long the period of time between those releases were (this is an example, of course) Well What is a lot. Migrating software from 3.1 to 3.3 shouldn't take much more than a day or so, since the incompatibilities should be mostly BBB marked. Once you have figured out how do move one specific API use or ZCML statement changing the reast of the same type is quick. I think this is (or should be) a non-issue. The problem with the changes, as mentioned before, is that it makes it hard to support more than two versions of Zope at once. So the problem is if you have one customer on Zope 3.1 and another on 3.3, using the same software, and the 3.1 guys refuse to let you upgrade. That's the problem. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On 9/5/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: And therefore, we really need to make an overview over all API changes from 3.0.0 so you can see what happened (this in addition to the more detailed whats new in vX pages. Maybe somebody can start such a page somewhere, and we can fill it in gradually? http://kpug.zwiki.org/WhatIsNewInZope33 That only covers 3.2-3.3. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re: Zope 3 as a reliable platform?!?
On 9/7/06, Rocky Burt [EMAIL PROTECTED] wrote: My experience so far... after not having touched a project for over a year and than the client wanting some work done, they usually expect to have to pay to have it upgraded. Well, in any case, they SHOULD expect that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
One thing that would be good is an overview of all API changes that have happened and in which version it happened. I guess that would be quite a bit of work, but a page like that would be very helpful if you wanna port an old app forward and skip a couple of versions. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c vs. the zorg
On 8/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: I actually think it would be *nice*, if not at all essential, to have a common namespace for community work. For such a common namespace z3c is a bit unwieldier than something like zorg. We could consider establishing a more coherent pattern in the future, perhaps. As mentioned in another thread, I'd like to avoid namespace clutter, but I have come to realize I have no good arguments for that. :-) So, if we can't agree, then it's just yet another namespace. zope, zc, lovely, schooltool, codespeak(?), nuxeo, z3lab, z3c and now zorg. If there is no interest in merging basic toolkits into the same namespace (which there overwhelmingly was not in the other discussion) then having both z3c and zorg can't be a problem either. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c vs. the zorg
On 8/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: Technically it isn't a problem, that's why it's not at all essential. But it might be nice for some other reasons: * people who write a new community package knows which namespace to use * we could present this to the outside world a bit more coherently; look at all these nice zorg components. I completely agree. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Riddle: zope.interface versus zope.formlib
On 8/23/06, Stephan Richter [EMAIL PROTECTED] wrote: If you ask zope.formlib (form.py, line 227):: # Adapt context, if necessary interface = field.interface ... adapter = interface(context) Here the answer would be: InterfaceClass __main__.IBar This seem like superfluous information to me. You can get that information from the field. I don't see what use it would be to store it on the attribute. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
On 8/21/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Again, like Fred said, this is a misconception. Eggs support a development mode [1]_ that registers a repository checkout as an egg. To setuptools, it's an egg, to you it's a checkout. Well, that still doesn't give me access to the repository. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
I'd like to throw a stick in the fire by taking up a completely different issue: The amount of top level modules and repositories. :-) if lovely.rating depends on schooltool.something, not only does this mean any usage of lovely.rating (which I imagine I would like to use) also needs one module form schooltool. In addition, we have whatever top level module I choose to use. That involves three different repositories, mine, zopes and schooltools, and three new toplevel modules. If I then throw in more modules that have more external dependencies, this will quickly mushroom. For example, I'd like to use ratings and tags with zblog. That means I need to involve the codespeak repository as well, and zblog has it's own top level module. And then I want a discussion forum (I don't think one of those exists) which presumably would have another top level module, and maybe another repository, and maybe more dependencies. So, what I'm saying is, that I would like to minimize the amount of top level domains, and external repository dependecies in the zope repo. That said, I think lovely is a lovely name, and don't at all mind having that as a common name for useable little modules like the tag and ratings module. :-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
On 8/19/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: What's the problem with top level packages? Nothing. But when we have loads of empty top level packages that each have a couple of modules it gets confusing, since you need to keep track of what does which. Eggs solves it for installations, but not fore developers which find and want to fix bugs. :-) I would much more prefer if we could keep all small useful packages in some sort of kommon namespace, which we know holds loads of small useful packages. If this in unfeasible, then fine, I'll just have to live with it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: NAG NAG NAG (Was: Let's have a bug day -- sort of)
On 8/11/06, Jim Fulton [EMAIL PROTECTED] wrote: :) I really wish some more people would help out -- not just the usual suspects. Well, I as usual oppose the friday bugdays, but that said, I have vacation this week, so this friday would work for me. Unless it's the only hot and sunny day of the week, in which case I'll go to the beach. :-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: NAG NAG NAG (Was: Let's have a bug day -- sort of)
On 8/12/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Lennart Regebro wrote: On 8/11/06, Jim Fulton [EMAIL PROTECTED] wrote: :) I really wish some more people would help out -- not just the usual suspects. Well, I as usual oppose the friday bugdays, but that said, I have vacation this week, so this friday would work for me. Thursday or Friday would work for me. Shall I make an announcement so that everybody joins in (perhaps the Zope 2/Five guys also want to particpate)? As for the goal, I suggest we try to have a Zope 3.3 release candidate by the end of that bug day. I'll be making another beta release this weekend, if no one objects. The first beta is really old now and has lots of packaging bugs (a few haven't even been fixed yet, like the missing test.py; I'm on that). So, even though a second beta wouldn't fix all reported bugs, it would at least fix the packaging bugs and a few other ones. I suspect I'll land 3.3beta2 some time Sunday afternoon CEST. Super stuff! -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Pluggable authentication id management
On 7/31/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: If you ask me, the slipping of the Zope 3 June release is mostly due to the lack of a release manager. If we had a release manager who'd kick people's asses, we might have more betas since the first one and we might even have a final release. Jup. Also, I think that just before christmas and just before vacations may not be good places. I'd like to suggest august/september and february/march for release dates. These may be equally bad for other reasons, though. Let's have a bug day this Friday. +100 -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The bug fixing problem
On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. Sure. The point of the tests is not to prevent this. The point of them is mainly to make sure that the thing you fixed says fixed. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
A small question/idea. When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified. in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an svn up, your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on. The benefit of that is that you don't by mistake check in on a tag... My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
On 6/26/06, Tres Seaver [EMAIL PROTECTED] wrote: - -1. The externals are just that, external to the Zope project. Uhm. I have a hard time seeing Five and lib/python/zope as external to Zope. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Yeah, with eggs this issue might go away... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Stable / Development branches?
On 6/21/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: There's nothing wrong with software being in production whose particular line isn't maintained anymore. I have Linux kernels 2.4 and Apaches 1.3 in production. What's your point? I checked what all my websites run. They are all on Zope 2.5. No problemas. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On 6/19/06, Chris Withers [EMAIL PROTECTED] wrote: Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now. Is it really? That's how it has been so far, yes. Maybe we should extend it. But mind you, that's more work... I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a I'd suggest there are lots of people still on 2.7.x. When 2.10.x is released imminently, are you saying that everyone will suddenly jump off 2.8.x? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On 6/19/06, Lennart Regebro [EMAIL PROTECTED] wrote: I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a Let me continue that. :) Supporting old versions must reasonably be a community effort, depending on if people have the time to do so. We can't just say three versions should be officially supported and then not doing it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] image libraries implementation in zope3 ?
On 5/26/06, Benji York [EMAIL PROTECTED] wrote: -0, I don't quite see the need to abstract away image manipulation libraries. I do. There are several of them, and at least the trivial stuff like resizing and format converting definitely can use an abstracted interface, so that you can resize, no matter what library you use. For more advanced stuff the abstraction seems pointless, the interface would be to specific anyway. But maybe it should be called IImageResizer, and IImageConverter, instead of trying to merge those very different interfaces into one. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
On 5/9/06, Jim Fulton [EMAIL PROTECTED] wrote: - Speed up restart. I think there are a lot of ways that restarts can be made faster: [...] o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. Just a brainstormy idea: One thing I like with Python imports which ZCML doesn't do, is that it only loads things that really are imported. Maybe there could be a way to say which products you depend on in ZCML, and only load the ZCML of these? Kinda like a zcml-import, but not creating problems if you import it twice? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.0 beta 1 released!
On 5/9/06, Egon Frerich [EMAIL PROTECTED] wrote: Zope 3 requires that Python 2.4.1 or newer be installed. so Python 2.5 should be possible when it is released. Future compatibility is impossible. Any such statement must be seen as Python 2.4.1, or later barring unexpected problems which we don't know of because we can't bloody well see into the future, can we? :-) Besides, in this case it means 2.4.1 or later version of 2.4, which maybe should be made explicit. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Automatic translation of message id's is deprecated and will be removed in 3.3
On 4/28/06, Gary Poster [EMAIL PROTECTED] wrote: Martijn proposed this be undeprecated (http://mail.zope.org/pipermail/ zope3-dev/2005-December/016781.html) and others agreed, at least in part. AIUI, Martijn ended up not making any changes in Zope 3, but somehow changing Zope 2 in such a way as to work around his issue. The deprecation certainly is a pain for those of us who have one template replacement that sometimes may be user entered (non-message ids) and sometimes may be automatically generated (message ids). Also, 3.3 is upon us, and the deprecation message claims that the behavior will be gone in this release. I would have time for simply removing the deprecation, not changing the behavior in any way. What's the consensus? The consensus was to undeprecate it, so I guess everybody just forgot to actually do it. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: The browser:page compromise
On 4/25/06, Bernd Dorn [EMAIL PROTECTED] wrote: On 25.04.2006, at 20:27, Lennart Regebro wrote: At https://svn.z3lab.org/z3lab/hello/trunk there is now a page this url seems to be broken No, it works fine, but only for svn (If you don't want to check it out and test it, you can browse the code here: http://svn.z3lab.org/trac/z3lab/browser/hello/trunk/ ) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: The browser:page compromise
At https://svn.z3lab.org/z3lab/hello/trunk there is now a page implementation that is easy to use and doens't do class generation. In fact, there are two versions, one that sets the __call__ attribute during instantiation, and one that uses browserDefault() and publishTraverse(). There is also an implementation of a template directive, that can be used for view-less templates, like Philipps implementation. It also has no class generation, but instead uses one empty view-class as a placeholder for all view-less templates. A pages directive for multiple pages is coming, and will possibly replace the page directive completely, to avoid uneccesary duplication. Comments are welcome. (If you don't want to check it out and test it, you can browse the code here: http://svn.z3lab.org/trac/z3lab/browser/hello/trunk/ ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/24/06, Tres Seaver [EMAIL PROTECTED] wrote: If we don't adopt a new namespace, perhaps 'browser:published'would serve as a 'nominalized adjective noun form of 'browser:publish'. one is called pageTemplate, how aboot calling the other pageAttribute? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/23/06, Andreas Reuleaux [EMAIL PROTECTED] wrote: I think the naming browser2:page vs. browser:publish vs. ... is not that important as the original name browser:page can be reintruduced (with the meaning of the new concept) after the deprecation period, i. e. I am thinking of having two (maybe three or four) different periods: We can't deprecate a zcml statement for the introducion of a statement that we know is gonna be deprecated. It makes no sense. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/23/06, Andreas Reuleaux [EMAIL PROTECTED] wrote: Sorry, I wonder if you read my suggestion carefully. In particular I suggested having a period where only the new (and ugly) statement is allowed, and only after that to reintroduce the old statment with a new meaning. Yes, so you suggest that we deprecate a statement for a statement that we intent to deprecate. And that just makes no sense. Such things (reintroduction of a known notation with a new meaning) are happening in the Python language itself as I pointed out, so I assume it makes some sense. Python 3 is to Python 2 and Zope 3 is to Zope 2. A big and intentionally largely incompatible rewrite, and can not be compared with this. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: A publishable view must provide IBrowserPublisher. We happen to call such browser views pages. This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. Sure. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Well, yes I do. I see that the code for the directives are less complex but it gets more complex for the users of these directives. The complexity has just moved. So it´s not actually more complex, just in different ways. I guess you can say that's why I´m -1 on the proposal. I'd like to get rid of complexity, not move it around. :-) Fixing the problem completely is certainly a pious wish, but we may never get there. Hence the compromise. I'm trying to improve what can be improved now. Just see how much of a fuss this tiny proposal made already. I know what you are trying to do, and I'm not saying that's a bad thing. I'm just saying that I don't really think this proposal does it, or at least not enough. :-) All I'm doing is trying to point out why this is so hard to fix, and maybe try to see if there is an alternative route. There are two parts to that requirement. 2a: Be a class that implements IBrowserView. IBrowserPublisher Right, sorry. 2b. Be callable. Which is expressed by IBrowserPage. Basically, IBrowserPage extends IBrowserPublisher by a __call__ method. Can we get rid of one of these? Why? Because that would fix the problem. What's wrong with having to implement a specific attribute (__call__)? Because it means that wee need to have one class per view. And that in turn means that we either have to have a lot of essentialy empty classes, or create magical classes dynamically. That in turn creates this complexity. I´m trying to see if we can get rid of it. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. No, you are suggesting to refactor them and maybe rename them. My #2 is to deprecate them completely and do nothing else. Which, I think, is what you wanted to do before, but loads of people (including me ;) ) screamed. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Is using a convenience base class really that much more complexity for the user? It's perhaps a little more typing, but it gives you less magic in return. Less magic is less complexity in a way. Depends on what you mean with convenience class. I don't mind convenient classes. But if I really need to create one class that does nothing except server as a placeholder for each of my pagetemplates, I wouldn't call that convenient. ;) So, basically, register pages and all other adapterish things with an adapter / directive? Fine by me :). Pretty much yes. ... hence the compromise :) Yup. And it seems the compromise was worse than the problem. ;) As Calvin sais: A good compromise leaves everybody mad. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: The browser:page compromise
I'm -1 on this proposal. I agree, browser:page is too complex and magic. The reason for it's complexity and magic is that there are two things that clash: 1. The need to have simple and easy view registrations, and 2. The requirement that view must be callable classes. The second requirements mean that you have to create a lot of callable classes that do nothing particularily useful. There can created by the programmer, which is a lot of stupid work. Requirement 1 sais that we shouldn't do that. The result is that we then create them automatically which creates a lot of hard to understand magic. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Evidently we do NOT want to get rid of requirement 1, because then people will again find making views a pain. Therefore, lets think about f we can get rid of requirement 2. There are two parts to that requirement. 2a: Be a class that implements IBrowserView. 2b. Be callable. Can we get rid of one of these? For example, could we have an optional argument on view registration that tells the view which attribute to be called? (I know, that's not possible when views are just adapters, it's an example). If we can't get rid of either 2a or 2b, we will either have to sacrifice requirement 1, and making views will be a boring pain, or have to have a lot of hard to understand magic with dynamically created classes. If we want to sacrifice the ease of registration, which this proposal does to a small extent I think we in that case should go all the way and remove the browser:page completely. It can in that case be moved out to a separate product for people like me, who want it. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Components in content add menus
On 4/21/06, Jim Fulton [EMAIL PROTECTED] wrote: I'm wondering if this is a problem. I'd say that as long as the register API adds them to the nearest site manager it is not a problem that you can add it anywhere else if you don't use that API. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Components in content add menus
On 4/22/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: You currently do as well. I think that's a good thing. In Zope 2 something was registered by simply being there. In the CMF, for example, you can't disable a tool unless you remove it or move it. Being registered is something different than existing... You are right. I´m getting used to seeing everything as nothing more than a type of adapter. It's your fault! :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposals vs. developer docs [was: Reducing the Amount of ZCML Directives ready for review]
On 3/20/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: In fact, I very much like how two other Zope-related projects handle this: Python with its PEPs and Plone with its PLIPs. When they describe the feature changelog of a major version, they can just point to the numbers of the PEPs and PLIPs and voila, you have a very visible list of what happened in a particular release. The same is also true for the feature roadmap (IOW, upcoming changes), as http://plone.org/products/plone/roadmap nicely demonstrates. I may not solve all of the problem, but it is still good. I agree, lets start numbering propsals. So, that's ehm, ZEP #0, then? :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
On 3/20/06, Tres Seaver [EMAIL PROTECTED] wrote: I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Good point. I think one major goal here (which to me seems to be reasonably satisfied by the proposal) is to make it easier to *use* zcml, more than to just make it smaller (which I think is a reasonable secondary goal). I put down some effort to make something similar to the faster-better-cheaper benchmark with Zope3, without copying existing code or skeleton code (although I didn't do timelogs, I did a contact-list, but that changes nothing in level of difficulty). And without any doubt, it's ZCML that is the big problem here, providing at least 2 out of 3 headaches. In fact, I only had one minor Python headache (I forgot that the object needs to be contained) and several rather major ZCML confusions. There are too many ways of doing things that sound like they possible may be the right way, but aren't. Simplficiation of this can be done in two ways: 1. Getting rid of the wrong ways. 2. Adding one new obviously correct way. Or any kind of mix of this. Note: The following is not a proposal, just reflection: What I ended up with was this: content class=.contact.Contact require permission=zope.Public interface=.contact.IContact set_schema=.contact.IContact / /content browser:defaultView for=.contact.IContact name=edit.html / browser:addMenuItem class=.contact.Contact title=Add Contact permission=zope.Public for=* / browser:editform for=.contact.IContact schema=.contact.IContact title=Edit Contact permission=zope.Public name=edit.html / Not too complex. But I did run up several wrong paths, like addform. And worse, addview, which as noted doesn't seem to even work, and is not needed in any case. But it's not obvious that you need neither an addform or an addview. I'm wondering if maybe this could not be simplyfied into something more like: content class=.contact.Contact viewing permission=zope.Public defaultView=edit.html / editing title=Edit Contact permission=zope.Public name=edit.html schema=.contact.IContact (with an optional view or template of you don't want a default edit form) / adding title=Add Contact permission=zope.Public for=* (with an optional view or template or interface if you want an add form) / /content This doens't really make the number of statements smaller, and it doesn't save very many lines of ZCML. But it *does* make it pretty darn obvious what to do. Because you can't do much else. Note again that this is not a proposal. I'm not saying we should do this. I'm just saying that simplifying can be done in several ways, and this would be one (not nessecarily good) way. (In fact, I think I like this, but it can without any problems be made into a separate product that adds this statement to ZCML, for simplified product creation). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Take on the Hello World Acid Test - from Mandatory Viewing
On 3/20/06, Stephan Richter [EMAIL PROTECTED] wrote: I think you should continue. :-) I too would like to see you continue. I did a quick test (not fulfilling the actual continuation) but just tried to make a small content class, without cheating by copy pasting code, and it was actually quite difficult. All in all it took me 74 minutes, gave me some headaches, and I had several barkings up the wrong three when it came to the ZCML. I'd like to see somebody else try to.. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Reducing the Amount of ZCML Directives ready for review
On 3/17/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: If no one objects to the branch as it is, I will merge it on the weekend. I am actively not objecting. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a plan for widgets?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: * Jim tells me Don't look at SimpleInputWidget, it's too complicated. This sounds wrong and zope2-like; something called Simple that's too complicated. We need to figure out how to make that story less complicated. Basically, it tries to be easily overrideable by create a whole host of methods that doesn't exist on other widgets, which you then can override. That basically makes no sense, if there is a function that should be easily overrideable, it should exist on a basic widget. Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. Are widgets tied to schema fields now? I have the feeling they are, but maybe not. If they are, they should be more decoupled. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a plan for widgets?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Just to interfaces of schema fields as views. The schema fields are in a hierarchy. I'm not sure how you would mean to decouple this. Anyway, my aim with this discussion is not to fundamentally overhaul the way widgets work, just to see what we can do relatively easily. Well, OK, one thing at a time. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Lennart Regebro [EMAIL PROTECTED] wrote: OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? None, evidently. So it was a bad brainwave then. :) Ah well. Beware the Ideas of March, as my grandad never said. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/15/06, Dieter Maurer [EMAIL PROTECTED] wrote: I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) I think that amongst web app frameworks we are. I don't know of any other aspect oriented ones. I could be wrong. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. Right you are, you don't even need to subclass it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer [EMAIL PROTECTED] wrote: Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). I tend to agree. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On 3/10/06, Martijn Faassen [EMAIL PROTECTED] wrote: For instance, one that looks like this: zope:annotation for=IBar factory=Foo / That doesn't look like configuration. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Take on the Hello World Acid Test - from Mandatory Viewing
On 3/9/06, Darryl Cousins [EMAIL PROTECTED] wrote: I enjoyed the fasterbettercheaper lecture. And it got me thinking about why I'm using Z3. Wanting to get that in words I took the hello world acid test: http://www.treefernwebservices.co.nz/hello.html You don't actually need the viewclass in the template case. -1 XML file. And you can add the package-include directly into site.zcml for an ugly hack. -1 XML file again. This too me 3 minutes to do, I have one XML file, and one page template and 0 lines of any non-html code. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mandatory Viewing!
On 3/7/06, Stephan Richter [EMAIL PROTECTED] wrote: I think currently Zope 3 would end up a little bit better than J2EE, but not much. I think it would be better than that. To do Hello World you need to define a browser:page for=* template=thetempate.pt permission=zope.View / One situp, no code except for the template. The second one requires you to define up the interfaces, make classes for it and add add forms and edit forms. Not good, but WAY ahead of J2EE. I also think that the priorities the narrator sets are real ones representing a lot of people. So let's discuss this movie a little bit and see how we could do well in his evaluation. Well, what I would like to see first is XForms based schemas/views, so you can use a WYSIWYG editor for that stuff. But the second and most important step here is to move these XForms in to the web, so you can do it TTW, but with the possibility to export it to disk when you want coding. But a TTW class editor with XForms and workflow, all nice an wysiwygy and you could make that application in Zope3 in 3 minutes. AND you could export it to a disk product if you need to write python code, and still use wysiwyg editors for the forms and the workflow. We are not that far off. Really. And a note to the people trying to make this a question about TTW. The product that did best was plone+archetypes, and that was not TTW. CPS has the possibility to do what he wants almost totally TTW with it's typemaker, but it would not have gained any extra points, I think, because that was not his point. He wants rapid turnarunds, which TTW can help with, but reloading of templates, schemas and workflows from disk takes you 90% there. And, Zope3 still has security and i18n for free. ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The vision thing
On 3/5/06, Geoff Davis [EMAIL PROTECTED] wrote: Jeff Shell has posted some thought-provoking pieces on his blog that are relevant to Jim's recent attempt to better articulate a vision for Zope: http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html I share some of Jeff's concerns. One thing that he has been doing that I think is really important for us is to systematically explore Django / TurboGears / Rails to see what they are doing that we can learn from. I have already seen several interesting posts from Jeff on this list and would love to hear more from him on the topic. I have two questions for everyone: * Can we address Jeff's concerns? If so, how? * What can we learn from Rails / Django / TurboGears? To me it seems mostly that one of his concerns are that we are having the vision debate instead of a vision. :-) The other one is the same olf concern: We have no website full of hype. The second one should be easy to fix, but I think out of a general concern for peoples sensibilities, nothing is happening. Too much talk, not enough hockey. The first one I have no solution for, except agreeing on a vision. Which for me seems dead simple, but of course, other don't agree. ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The vision thing
On 3/5/06, Jim Fulton [EMAIL PROTECTED] wrote: I think that one of the first steps is to agree on who our target audiences are and target them individually. Zope has a number of target audences, including: - Non-technical users who just want to crank our a web application with little muss and fuss. This was the original focus of Zope 2 and now Plone. - People who know what an app server is and know they need one. People who know they need to reuse applications and need tools to customise them. People who know they need rich servcies, like security, transactions, etc. These are the people for whom Zope 3 was written. - People who want straightforward tools for developing small to moderate complexity sites in Python. I don't think we are servving this audience well. Then there are more fragmented audiences, like people who want a dirt simple way to create applications based on relational databases. My main point is that we need to consider each of these audiences, as they have separate concerns. We need to be explicit about this and have messages and technical solutions tailored to each audience. Right you are. Good refocusing post. :-) Zope3 does of course cater to audience #2 very well. Superbly even. It does not cater to audience #1 at all, and notably, don't think it should. Why? Because most of them do not want a set of tools, they want a complete CMS, or at least a framework and a large set of bits which you can stick on easily. The effort to cater to these people should be something written for or on or with Zope3, not a part if Zope3 itself, and includes such things as TTW development products and CMS stuff. We are evidently not serving audience #3 well, because they are complaining. I'm not sure what to do except make Zope3s basic bits easier to use by themselves, which everybody agrees to. So maybe we need THREE visions, and not one? Vision #2 (starting with that one because it's easier): Improving Zope3, refactoring a bit, putting ZCML on a diet and so on. All this seems to me to be straight on track, or? Vision #1: A CMS framework and TTW tools for Zope3. Vision #3: Eggs for the basic technologies. So where is Five and Zope2 in all this? Well, it continues to be an an upgrade/transition path for people that are using Zope2 now, but want to slowly move over to the #1 vision. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The vision thing
On 3/5/06, Max M [EMAIL PROTECTED] wrote: I could probably do one that is a lot more impressive with an UML tool, Plone, archetypes and ArchgenXML. And it would most likely last 10 minutes... if I talked very very slowly. But that is not the point. YES IT IS! Do it! We need the hype! -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-Users] Re: [Zope3-dev] Visionaire! (All your problems, solved)
On 3/4/06, Dieter Maurer [EMAIL PROTECTED] wrote: You can find drastic changes in the technology names (rather than the product names): e.g. COM, OLE, ActiveX, COM+ This is a silly pseudo-discussion, but I continue it for fun. ;-) COM, OLE and ActiveX are not the same thing. COM is an object component model, OLE is an extension of that for document objects, and ActiveX is a set of technologies of which COM and OLE are some. It's not exactly a drastic name change of what is basically the same. Maybe MS have done that from time to time, but it's definitely not something they do very often. Examples of when things have changed name is when PCMCIA changed name to PC-card. They have had to live with both names forever. I can't think of any product wh has had a successful name change after it's widespread release. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] visions, brands and roadmaps in the sand
On 3/3/06, Dieter Maurer [EMAIL PROTECTED] wrote: MS renames its core technologies every few years (at least) Eh... no they don't. It's been called MS Windows, and MS Office and the like for like 15-20 years now. :-) In fact I can't think of any case where Microsoft have renamed any technology... They do however from time to time rewrite things completely from scratch, but keep the name. :-) Windows 2, Windows 3 and NT have completely different code bases, but the same name. They did however include reasonable backwards compatibility from the start, which Zope3 didn't. And yes, that caused some problems, but since Bill Gates don't pay us, it was necessary. Heck, MS Basic was a core technology between the start of the company and up until C# came along, and I defy you to try to run a 1970s MS Basic program in the MS Word Basic extension! :-p -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
The idea has some benefits, but I'm not very sure it's a good idea. If it should be implemented, this is how I would like to see it: On 3/2/06, Jeff Shell [EMAIL PROTECTED] wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. No, I don't think it should be easy to deploy against anything in. It should be so stripped down that it isn't about web anymore. No server. Just the component architecture. The component architecture is a great architecture even for non-web development. zope.interfaces, .components, .i18n*, .testing. Maybe even .configuration and .thread? Now, if you want to use the CA for web deployment, but not the whole Zope, you can easily add the publisher and pagetemplates and so on to your toolstack. But the component architecture is NOT about web. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. I don't see a need for this. I think this level should be the end product, ie, Plone 3, CPS4, Silva Something. A midlevel Suite with which you still can't do shit without development seems pointless. Separate product packages like ecm support, and Zope2 backwards compatibility and such makes sense. The Suite does not. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
