Re: [Zope3-dev] status of zc.page?
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] * the snapshot is probably aging as bugs get discovered and fixed in your repository. Could you perhaps update the snapshot? Sure. Looking forward to the update, though we haven't found bugs yet in our experiments so far. I'm note sure there have been changes since the last snapshot. Initial feedback: Overall: it's definitely an improvement above the ZCML directives! We often need to build template specifically, just calling widgets/foo/render inside our own template that's completely particular to that form. This worked well, until I had to figure out how to render an action. I finally accomplished it by using view/actions/form.action.name/render, where 'name' is a lowercased from the one you put in the decorator and what will also appear on the button. Hm. I'll look at this. This didn't feel ideal; the prefixing was hard to figure out initially (should at least be better documented), and basing the internal name on the displayed one doesn't feel right. I'll look at this and at the documentation. Actions have a number of issues and I'm not sure the doctests fully reflect them. I want to take a look at this and then provide a new snapshot. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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: [Zope-dev] Zope 2.9 goals
There's a thread over on zope-dev that I think is relevent to Zope 3. I'm going to resend a few messages of mine here FYI. Martijn Faassen wrote: Hi there, Since Zope 2.8 has now been released, we can start talking about what would be in Zope 2.9. Yup. I'll just remind everybody that, starting with Zope 2.9 and Zope 3.2, we are switching to time based, rather than feature-based releases. We will make feature releases of Zope 2 and Zope 3 every 6 months, starting this December. I suggest a manditory feature freeze at the beginning of the previous month, so November 1 for the next releases. I have some ideas: * newer version of Five included (whatever version is current then) * Zope 3.1 included Actually, Zope 3.2. Zope 3.2 and 2.9 will be released together, There is no need for Zope 2 to be a release behind in it's Zope 3 components. * Python 2.4 support I think these could all be accomplished without getting too ambitious. Yes. I think this is a good starting point. I hope there will be more, but, since we are doing time based release from now on, we'll have what we have. Especially the Five work and Zope 3.1 work will mostly happen anyway, so integration should be relatively easy. I don't know much about how involved Python 2.4 support would be; perhaps people who know more can speak up. The biggest issue with new Python versions is a security audit to make sure that new Python features don't create security holes. This is especially problementic for Zope 2's current security architecture, which relies on specialized Python compilers. I would *love* to change Zope 2 to use more of Zope 3's security architecture, although I don't know if I'll have time to do that. If someone wants to volunteer for some deep work, I think this would be extremely valuable. Then there's something I know little about, but is also believed planned for Zope 2.9: * blob storage, file iterators I believe the work on this is fairly far along already. Yes, probably. I'd be happy if this was *all* that changed in Zope 2.9. This way we can release Zope 2.9 in the forseeable future, like, late this year. If Zope 3 is on track there will already be a Zope 3.2 release imminent by then, but I'm okay with Zope 2.x running a version behind in the name of getting things out of the door to the developers. What do people think? I think it is good to plan work, but, *we will not be bound by a specific set of features*. We are switching to time-based releases for Zope 2 and Zope 3. Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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: [Zope-dev] Re: Zope 2.9 goals
Martijn Faassen wrote: Jim Fulton wrote: Max M wrote: Jim Fulton wrote: Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Will they have the same relase date or will they be offset by a few months or something? They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations. This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious? Actually, I think that time-based releases make planning fairly easy. There *will absolutely* be a Zope (23) feature freeze and beta release November 1 (or sooner if we think that this leaves too little time for a beta cycle). There *will* be a final release in December, come hell or high water. If you think this is to ambitious, then lets move the freeze/beta up to give us more time for bug fixes, say October 1? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Choose-a-name strategy and write conflicts
The use of INameChooser is useful for picking names that don't conflict across serial transactions. But this approach is problematic when two or more transactions are tying to add objects to a container at the same time. Because 'choose name' relies on its isolated version of a container, multiple threads are destined to choose the same name (assuming non-random algorithm), resulting in a write conflict. In some cases a write conflict is a normal and healthy thing to get, particularly if you let users edit the same object at the same time without care. But adding new objects to a container when the names are chosen by the system should not cause this problem. E.g. if the objects use unique keys, the BTree conflict resolution should gracefully handle the concurrent adds. The only solution that occurs to me is to use an alternate persistence mechanism (e.g. a file or database) for 'next name' sequences and control access to it via a thread lock. Is there a way to do this in the ZODB without the use of some external file-locking/update mechanism? Does this problem even make sense to people, or have I lapsed into garbled nonsense (again) :-) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Choose-a-name strategy and write conflicts
Garrett Smith wrote: The use of INameChooser is useful for picking names that don't conflict across serial transactions. But this approach is problematic when two or more transactions are tying to add objects to a container at the same time. Because 'choose name' relies on its isolated version of a container, multiple threads are destined to choose the same name (assuming non-random algorithm), resulting in a write conflict. In some cases a write conflict is a normal and healthy thing to get, particularly if you let users edit the same object at the same time without care. But adding new objects to a container when the names are chosen by the system should not cause this problem. E.g. if the objects use unique keys, the BTree conflict resolution should gracefully handle the concurrent adds. The only solution that occurs to me is to use an alternate persistence mechanism (e.g. a file or database) for 'next name' sequences and control access to it via a thread lock. Is there a way to do this in the ZODB without the use of some external file-locking/update mechanism? Does this problem even make sense to people, or have I lapsed into garbled nonsense (again) :-) It's only a problem for large shared containers that people are very likely to add to at the same time, so it's a somewhat specialized problem. If people don't actually care about ids, you could generate them randomly. Another common scheme is to use high-precision times in th names. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
