Re: Apple's mailer is annoying ( was Re: [Zope3-dev] Contained events interface inheritance order)
Yesss! Good, Old Style Mac vs everything Platform Wars! :-) Ah... the 90's, what times those were... /dario - lost in old memories ;-) -- -- --- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Apple's mailer is annoying ( was Re: [Zope3-dev] Contained events interface inheritance order)
Jim Fulton wrote: ... There is no way for my mail client to know that "http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/"; and "SimplifyObjectLifecycleAndLocationEvents" should be clued together. URLs often end in "/"s. Implicitly joining text following a "/" is fairly likely to lead to invalif URLs. Never mind. The trailing space is the signal that this was a soft break. I still agree with Tres that breaking URLs is incorrect. :) 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
Re: Apple's mailer is annoying ( was Re: [Zope3-dev] Contained events interface inheritance order)
On 30 Nov 2005, at 21:03, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. I don't see how. Here's an excerpt of the raw source of your message: " From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the" There is no way for my mail client to know that "http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/"; and "SimplifyObjectLifecycleAndLocationEvents" should be clued together. URLs often end in "/"s. Implicitly joining text following a "/" is fairly likely to lead to invalif URLs. Actually in the raw source there's a space after the / and before the CRLF. When delsp=Yes (which is the case in the original headers Apple Mail sends), and when the line is deemed "flowed" (which is the case here because the line ends with a space), the lines should be joined and one space character removed. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Apple's mailer is annoying ( was Re: [Zope3-dev] Contained events interface inheritance order)
Florent Guillaume wrote: On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. I don't see how. Here's an excerpt of the raw source of your message: " From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the" There is no way for my mail client to know that "http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/"; and "SimplifyObjectLifecycleAndLocationEvents" should be clued together. URLs often end in "/"s. Implicitly joining text following a "/" is fairly likely to lead to invalif URLs. 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
Re: [Zope3-dev] Contained events interface inheritance order
On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Contained events interface inheritance order
Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? 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
Re: [Zope3-dev] Contained events interface inheritance order
On 30 Nov 2005, at 13:17, Jim Fulton wrote: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Contained events interface inheritance order
Hi Jim and Florent [...] > > I suggest: > > - Rename IObjectMovedEvent to IObjectLocationEvent. The old name >would be retained as an alias and deprecated. Please use a verb like IObjectLocatedEvent instead of IObjectLocationEvent. > - Create a new event, IObjectRelocatedEvent that extends >IObjectLocationEvent and is generated whan an object is moved, >but not added or removed. Possibly, down the road, > "relocated" could be >renamed to "moved". > >In your first use case, you'd register the subscriber for > both added >and relocated. In your second, for just relocated. You > could so something >similar for your before events. > > - If necessary, intermediate event types could be defined to avoid >the duplicate registrations. > > Of course, this would be for the June release. It will also > cause spurious > test failures. We really need to have better ways to make > assertions about > event histories. Regards Roger Ineichen > 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/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Contained events interface inheritance order
Florent Guillaume wrote: Today the contained events interfaces are: class IObjectMovedEvent(IObjectEvent) class IObjectAddedEvent(IObjectMovedEvent) class IObjectRemovedEvent(IObjectMovedEvent) From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the motivation... Before that proposal, the hierarchy was: class IObjectAddedEvent(IObjectEvent) class IObjectRemovedEvent(IObjectEvent) class IObjectMovedEvent(IObjectAddedEvent, IObjectRemovedEvent) Note that before the refactoring, separate add and remove events were published on a move. This is the most important aspect of the change. You often want to handle just add events or just removed events. For example, you only want to generate an integer id on an add event and you only want to remove it on a remove event. "Added" means that something that didn't have a location now has one. Similarly, "removed" means that something no-longer has a location. This meaning isn't captured by the old hierarchy. It's a shame this wasn't captured in the proposal. I contend that this second hierarchy is much more useful to deal with. The arguments I have are in the use cases explained in: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) where you can see the hoops one has to go through to react to objects being created, deleted or moved with the current event hierarchy. You mean "added", "removed", or "moved". In your third use case, I'll note that you can compute the old path using information in the event. This is why Zope 3 doesn't need the before event. My understanding was that the before event was added to more closely match the semantics of manageBeforeDelete. I'd like to know what non-framework use cases people have today with the current event interfaces hierarchy, and if they really find it more useful than the old one. The concepts of "added" and "removed", as described above, are valuable IMO. If not, or if the use cases are borderline, I'd like to propose that the hierarchy be moved back to the second form. This would have to go through a deprecation phase, I'm not sure exactly how, but if there's consensus we can find a way. I suggest: - Rename IObjectMovedEvent to IObjectLocationEvent. The old name would be retained as an alias and deprecated. - Create a new event, IObjectRelocatedEvent that extends IObjectLocationEvent and is generated whan an object is moved, but not added or removed. Possibly, down the road, "relocated" could be renamed to "moved". In your first use case, you'd register the subscriber for both added and relocated. In your second, for just relocated. You could so something similar for your before events. - If necessary, intermediate event types could be defined to avoid the duplicate registrations. Of course, this would be for the June release. It will also cause spurious test failures. We really need to have better ways to make assertions about event histories. 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
