Re: Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)
On 10/9/06, Jean-Marc Orliaguet <[EMAIL PROTECTED]> wrote: That's basically what I wrote the other day (The Times... ) : as an application designer you want a *plugin architecture* with greasy fat components, not an architecture with hundreds of micro-components wired together like this: http://jacobswellchurch.org/tim/archives/wires-bottom.jpg that require that learn the internals. Also, "plugin logic" is not the same as "micro-component logic": - plugins are single units that only need a runtime platform to get working, while micro-components need to get assembled before they can be used, the border between the platform and the platform's components is very blurry. - plugins have a public API that preserves backward compatibility, and hence preserves user's investments, while micro-components neither have a public or private API, they implement interfaces (interface != API) - plugins can get loaded and unloaded at runtime, or updated, while micro-components are basically added once at server startup time and they never get changed at run-time. - a plugin architecture can manage dependencies between plugins. - plugins are useful to market an architecture, (cf. Photoshop gimp, Gimp plugins, VDR plugins (http://www.cadsoft.de/vdr/plugins.htm), Firefox plugins, skins, Azureus plugins, Eclipse plugins ...). It is easy to explain what a plugin does in terms of functionality, while it is difficult to explain what a micro-component does. //- plugins encourage participation!!! (that's one of the reason of the success of Plone IMO: every one feel that they can create their own product, by looking at other existing products), while micro-components are difficult to grasp. - plugins can be used by end-users, while micro-components are designed by developers for developers. That's not at all what I said. ;) But you have valid points and I basically agree with your separations of micro-components and plugins. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.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 )
[Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-10-9 19:59 +0200: > ... >Sure, you CAN try to >reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. >from ReuseUtils), but most of these revolve more around implementation >details than around well-defined APIs and responsibilities. This must mean "most of those you know of" and not "most of my tools" :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Andreas Jung wrote at 2006-10-9 19:24 +0200: > ... >We have some code where some classes have up to 15(!) base classes (usually >mixin classes), not counting classes inherited from the mix-in classes. I >would call that unmanageable. Each of these classes represent a mixed in feature. You get 15 classes because the end result needs a lot of features. Manageability does not increase when you implement the features differently than listing them in the inheritance clause. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)
Lennart Regebro wrote: On 10/9/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: > ... >> I find that the introduction of classes with (multiple) inheritance >> has been very economic. It was another concept but a highly fruitful >> one, despite the fact that they are not so liked in Zope3 land. > >I think "fat" objects from mixing many different concerns into a single >implementation are a failed approach. > >Seeing how flexible you can be wit > > a) separating concerns (functionality, responsibilities) into >separate objects called components and > > b) making the lookup of these components pluggable (using registries >a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. >I would not recommend anyone to over-use multiple inheritance as it's >been done in Zope 2. I am a strong favorite of (multiple) inheritance and use it excessively. I have the feeling that it makes me very productive. There is of course no conflict between the two attitudes. It may *look* like there is, though. ;) In one case, you make loads of small objects with separate concerns, and merge them into one object by multiple-inheritance. In the other case you make loads of small objects with separate concerns and merge them via adapters. The first version is less flexible, as changing the behaviour of the resulting "fat" objects requires subclassing, while the other attitude can be hard to overview and grasp (and hence, I'll call it "greasy". Haha.) I think one generally should, in Zope3/Five, use objects as if they always need to be adapted. That is, you get the context, and you adapt it to whatever interface you need, with IMyinterface(context). Then, of course, you may very well make your object a fat object that implement all the bloody interfaces you need, instead of having multiple sets of objects and adapters, which in most cases just make things complicated. But with this attitde, that is make fat objects, but never assume they are fat when you use them, you can with little effort make something flexible. For example: The CalZope calendar attaches all views directly to the ICalendar interface. Only ICalendar objects can have these views. A calendar object in CPS is therefore a calendar that directly implements ICalendar, and some other extended interfaces with CPS support and stuff. This seems perfectly reaonable, but it turns out Plone people don't want that. They want ordinary folder to have these views. The solution to that is to attach all the views to "ICalendarViewable" and in all views make self.context = ICalendar(context), and this way adapt the context. By making my fat calendar objects IcalendarViewable, I need not to change any other code in CPSSharedCalendar or CalZope. I still have the same monolithic objects, that are easy to understand and debug. But for Plone, it would with these changes be perfectly possible to make adapters from Plone folders to ICalendar, and therefore use CalZope views for folders full of plone events. So, as long as you *use* the objects as if they always need to be adapted, you can very well write the objects monolithically if that suits you. So, heres a new tagline: "Use your objects as if they were greasy, and it isn't a problem if they are fat." ;-) That's basically what I wrote the other day (The Times... ) : as an application designer you want a *plugin architecture* with greasy fat components, not an architecture with hundreds of micro-components wired together like this: http://jacobswellchurch.org/tim/archives/wires-bottom.jpg that require that learn the internals. Also, "plugin logic" is not the same as "micro-component logic": - plugins are single units that only need a runtime platform to get working, while micro-components need to get assembled before they can be used, the border between the platform and the platform's components is very blurry. - plugins have a public API that preserves backward compatibility, and hence preserves user's investments, while micro-components neither have a public or private API, they implement interfaces (interface != API) - plugins can get loaded and unloaded at runtime, or updated, while micro-components are basically added once at server startup time and they never get changed at run-time. - a plugin architecture can manage dependencies between plugins. - plugins are useful to market an architecture, (cf. Photoshop gimp, Gimp plugins, VDR plugins (http://www.cadsoft.de/vdr/plugins.htm), Firefox plugins, skins, Azureus plugins, Eclipse plugins ...). It is easy to explain what a plugin does in terms of functionality, while it is difficult to explain what a micro-component does. //- plugins encourage participation!!! (that'
[Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: ... I find that the introduction of classes with (multiple) inheritance has been very economic. It was another concept but a highly fruitful one, despite the fact that they are not so liked in Zope3 land. I think "fat" objects from mixing many different concerns into a single implementation are a failed approach. Seeing how flexible you can be wit a) separating concerns (functionality, responsibilities) into separate objects called components and b) making the lookup of these components pluggable (using registries a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. Perhaps. That's to be seen. For one, the CA's registries are much less magic because look-up is always explicit (as opposed to the implicit acquisition as its widely used in Zope 2). I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. This is indeed a good point. There are currently efforts to make Zope 3 easier for simpler use cases that wouldn't involve dealing with those registries, at least not directly. In fact, we're having a sprint on this topic this month. I would not recommend anyone to over-use multiple inheritance as it's been done in Zope 2. I am a strong favorite of (multiple) inheritance and use it excessively. I have the feeling that it makes me very productive. That's good. Again, I think multiple inheritance is a valid tool. One reason why I would advise against using is excessively, though, is the lack of pluggability. The way Zope 2 deals with APIs, for example, makes hard to reuse and customize existing components. Sure, you CAN try to reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. from ReuseUtils), but most of these revolve more around implementation details than around well-defined APIs and responsibilities. ___ 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 )
Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)
On 10/9/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: > ... >> I find that the introduction of classes with (multiple) inheritance >> has been very economic. It was another concept but a highly fruitful >> one, despite the fact that they are not so liked in Zope3 land. > >I think "fat" objects from mixing many different concerns into a single >implementation are a failed approach. > >Seeing how flexible you can be wit > > a) separating concerns (functionality, responsibilities) into >separate objects called components and > > b) making the lookup of these components pluggable (using registries >a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. >I would not recommend anyone to over-use multiple inheritance as it's >been done in Zope 2. I am a strong favorite of (multiple) inheritance and use it excessively. I have the feeling that it makes me very productive. There is of course no conflict between the two attitudes. It may *look* like there is, though. ;) In one case, you make loads of small objects with separate concerns, and merge them into one object by multiple-inheritance. In the other case you make loads of small objects with separate concerns and merge them via adapters. The first version is less flexible, as changing the behaviour of the resulting "fat" objects requires subclassing, while the other attitude can be hard to overview and grasp (and hence, I'll call it "greasy". Haha.) I think one generally should, in Zope3/Five, use objects as if they always need to be adapted. That is, you get the context, and you adapt it to whatever interface you need, with IMyinterface(context). Then, of course, you may very well make your object a fat object that implement all the bloody interfaces you need, instead of having multiple sets of objects and adapters, which in most cases just make things complicated. But with this attitde, that is make fat objects, but never assume they are fat when you use them, you can with little effort make something flexible. For example: The CalZope calendar attaches all views directly to the ICalendar interface. Only ICalendar objects can have these views. A calendar object in CPS is therefore a calendar that directly implements ICalendar, and some other extended interfaces with CPS support and stuff. This seems perfectly reaonable, but it turns out Plone people don't want that. They want ordinary folder to have these views. The solution to that is to attach all the views to "ICalendarViewable" and in all views make self.context = ICalendar(context), and this way adapt the context. By making my fat calendar objects IcalendarViewable, I need not to change any other code in CPSSharedCalendar or CalZope. I still have the same monolithic objects, that are easy to understand and debug. But for Plone, it would with these changes be perfectly possible to make adapters from Plone folders to ICalendar, and therefore use CalZope views for folders full of plone events. So, as long as you *use* the objects as if they always need to be adapted, you can very well write the objects monolithically if that suits you. So, heres a new tagline: "Use your objects as if they were greasy, and it isn't a problem if they are fat." ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.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 )
Re: [Zope-dev] Re: Future of ZClasses
--On 9. Oktober 2006 19:11:55 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: I would not recommend anyone to over-use multiple inheritance as it's been done in Zope 2. I am a strong favorite of (multiple) inheritance and use it excessively. I have the feeling that it makes me very productive. We have some code where some classes have up to 15(!) base classes (usually mixin classes), not counting classes inherited from the mix-in classes. I would call that unmanageable. Personal productivity is one side of the medal, readability and understandability of code for other team member is the other side of the medal. Although I am not the biggest fan of the component architecture I have to admit that it makes a lot of things clearer and cleaner. -aj pgpyPNxGod5GG.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: > ... >> I find that the introduction of classes with (multiple) inheritance >> has been very economic. It was another concept but a highly fruitful >> one, despite the fact that they are not so liked in Zope3 land. > >I think "fat" objects from mixing many different concerns into a single >implementation are a failed approach. > >Seeing how flexible you can be wit > > a) separating concerns (functionality, responsibilities) into >separate objects called components and > > b) making the lookup of these components pluggable (using registries >a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. >I would not recommend anyone to over-use multiple inheritance as it's >been done in Zope 2. I am a strong favorite of (multiple) inheritance and use it excessively. I have the feeling that it makes me very productive. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Maintainer of Zope 2 Windows builds?
On Mon, Oct 09, 2006 at 12:19:22PM -0400, Tim Peters wrote: | You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make | Windows releases. It was at best half nuts that I kept doing it after | building & testing an installer once each N weeks became my only contact | with Zope. I'm using Zope on Windows on a daily basis now. So that might mean me. :) I would like to propose setting up some sort of 'nightly build' using the buildbot already in place. We can setup it so that you don't need to change the buildbot config to point it to another release. Then whenever a release tarball is done, we poke the buildbot and an installer will show up. If the installer breaks we get some visibility at least. I'm already running a slave for pybots which has all the needed tools in place. It wouldn't require much effort to add a Zope Installer build to that. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Maintainer of Zope 2 Windows builds?
--On 9. Oktober 2006 12:19:22 -0400 Tim Peters <[EMAIL PROTECTED]> wrote: Don't know about "should be", but it /is/ related ;-) I had job-related reasons before to make at least minimal ongoing efforts toward keeping the Zope test suites happy on Windows, and that in turn meant I kept many full checkouts of various Zopes current, at least ran the tests routinely, gave real attention to discussions of possible Windows glitches, built Windows installers routinely, and so on. But I don't do anything related to web development anymore, and "bit rot" is setting in wrt my once-encyclopedic knowledge of the umpteen quirky build procedures for the umpteen versions of Windows Zope. When, months ago, someone else volunteered to take over the Zope3 Windows builds, and actually followed up on it (yay!), I mentally resigned from these tasks. You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make Windows releases. It was at best half nuts that I kept doing it after building & testing an installer once each N weeks became my only contact with Zope. Thanks for your work on the windows builds in the past. We appreciate your work very much. I built the last couple of Zope 2.9.x release, but my access to a Windows build environment is gone now... Odd. I believe Tim built 2.9.4 because you could not? I don't remember, but it's possible. I'm still willing to build an installer when there's no alternative, but it's long past time that was treated as a last-ditch fallback instead of "business as usual". I'd like to see someone taking over the responsibility for the Windows builds for the mid-term future. We have enough smart Windows users that could step in. Thanks in advance, Andreas pgpqEsVoDY0ju.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Maintainer of Zope 2 Windows builds?
[Andreas Jung] Who is currently in charge or who feels responsible for the Windows builds? [Sidnei da Silva] Tim Peters. [Chris Withers] Er, no. Tim isn't even at Zope Corp anymore, as far as I know... [Sidnei] That shouldn't be related, should it? Don't know about "should be", but it /is/ related ;-) I had job-related reasons before to make at least minimal ongoing efforts toward keeping the Zope test suites happy on Windows, and that in turn meant I kept many full checkouts of various Zopes current, at least ran the tests routinely, gave real attention to discussions of possible Windows glitches, built Windows installers routinely, and so on. But I don't do anything related to web development anymore, and "bit rot" is setting in wrt my once-encyclopedic knowledge of the umpteen quirky build procedures for the umpteen versions of Windows Zope. When, months ago, someone else volunteered to take over the Zope3 Windows builds, and actually followed up on it (yay!), I mentally resigned from these tasks. You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make Windows releases. It was at best half nuts that I kept doing it after building & testing an installer once each N weeks became my only contact with Zope. I built the last couple of Zope 2.9.x release, but my access to a Windows build environment is gone now... Odd. I believe Tim built 2.9.4 because you could not? I don't remember, but it's possible. I'm still willing to build an installer when there's no alternative, but it's long past time that was treated as a last-ditch fallback instead of "business as usual". ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving ZopeVersionControl to subversion?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Oct 2006, at 18:55, Jens Vagelpohl wrote: On 6 Oct 2006, at 17:38, Wichert Akkerman wrote: I noticed that ZopeVersionControl is still actively maintained in CVS. Would its maintainers mind moving it to subversion? That would make it a lot easier for us to include it in the Plone 3.0 bundle. I don't think it *has* a maintainer... I think the sandbox for moving items from CVS to SVN that I built on cvs.zope.org for items like CMF and PAS still exists and I could do the physical move. I'm afraid I spoke too soon. My sudo access has been removed. Jim tells me any task requiring root access must be performed by him (or other ZC staff I presume). I'm hereby "un-volunteering" myself from this task. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFKnDiRAx5nvEhZLIRAvZ9AJ9sPCZFrIGr8MOxfNBLEtkjzd+1pgCfbqDl O7aaWFvHT1o90GhvibrRXjg= =Q86p -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Maintainer of Zope 2 Windows builds?
On Mon, Oct 09, 2006 at 03:25:55PM +0100, Chris Withers wrote: | Sidnei da Silva wrote: | >On Sat, Oct 07, 2006 at 09:25:29AM +0200, Andreas Jung wrote: | >| Who is currently in charge or who feels responsible for the Windows | >builds? | > | >Tim Peters. | | Er, no. Tim isn't even at Zope Corp anymore, as far as I know... That shouldn't be related, should it? | I built the last couple of Zope 2.9.x release, but my access to a | Windows build environment is gone now... Odd. I believe Tim built 2.9.4 because you could not? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Moving ZopeVersionControl to subversion?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles Waller wrote: >> >> I noticed that Tres was making changes in CVS and preparing a 0.3.2 >> release, so there is at least some activity. >> > > That was me ... I badgered Tres into incorporating a patch I'd put into > the tracker. Before that there was no activity. > > It definitely doesn't have a maintainer. There are clues that there are > people out there using it, but noone has admitted so 'in the open'! I don't see a problem with moving ZVC into Subversion; I do think that those who have an interest in it should work together to name a maintainer (and I'm *not* volunteering ;) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFKmuz+gerLs4ltQ4RAiPzAJ4qw4dzq1kqYgW+HsLpn3b0n2OVzQCfWYOV eWFTWVEWDfr0tpoQBvCWbqc= =fRmI -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Maintainer of Zope 2 Windows builds?
Sidnei da Silva wrote: On Sat, Oct 07, 2006 at 09:25:29AM +0200, Andreas Jung wrote: | Who is currently in charge or who feels responsible for the Windows builds? Tim Peters. Er, no. Tim isn't even at Zope Corp anymore, as far as I know... I built the last couple of Zope 2.9.x release, but my access to a Windows build environment is gone now... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Moving ZopeVersionControl to subversion?
I noticed that Tres was making changes in CVS and preparing a 0.3.2 release, so there is at least some activity. That was me ... I badgered Tres into incorporating a patch I'd put into the tracker. Before that there was no activity. It definitely doesn't have a maintainer. There are clues that there are people out there using it, but noone has admitted so 'in the open'! Miles ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] (no subject)
与美女视频聊天直播，按此进入 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] (no subject)
___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] (no subject)
___ 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 )
