[Zope-dev] two-phase-commit question
ZOPE_HOME/lib/python/Shared/DC/ZRDB/TM.py Glancing over the Transaction TM mixin class... i noticed a line commit=tpc_abort=tpc_begin i can understand tpc_begin=commit, but the abort seems strange. if an abort happens in the two phase commit the equality doesn't make sense to me. whats going on here? Is this meant to be overidden? TIA Kapil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
At 03:14 PM 9/29/00 -0500, Steve Spicklemire wrote: > >Thanks so much for the response... > >It turns out, I tried the Python Method and it had the >same basic problem as the DTML Method... however I've now >moved on, using deletageRetrieve to a new thorny issue. ;-) > >When I get an object from of another specialist it appears >that it doies not inherit from my specialist, but from >*its* specialist. (e.g., my framework specialist has methods >that I want the dataskins to acquire). I've currently got it >wrapped like so: > >def retrieveItem(self, key): >""" get an item""" >return self.delegateRetrieve(self, None, key=key).__of__(self) > >I've tried several different combinations of __of__ etc, but >none of them seems to allow the dataskin to acquire, for example, >standard_html_header from my specialist. Is there any way to >enforce acquisition at this level? You can use aq_base before the __of__, but I wouldn't recommend it, because you'll be forcibly ripping off security-related data. Probably aq_explicit would work better, since it would prevent default acquisition but leave security acquisitions relatively intact. I still suspect, though, that your design is not optimal. If you actually need a "bridge" specialist that lets you change the behaviors of the thing you're accessing, then you should really just build a bridge specialist and not simply do directly delegated retrieval. What you want is to set up a rack in the specialist that creates a virtual object which gets all its attributes (the ones you care about, anyway) from an object retrieved from the other specialist. SkinScript example: WITH otherSpecialist.getItem(self.id) COMPUTE theRealThing = (RESULT is None) and NOT_FOUND or RESULT WITH self.theRealThing COMPUTE myAttr1 = RESULT.theirAttr1, myAttr2 = theirAttr2, # equivalent to myAttr2 = RESULT.theirAttr2 SomeAttr, # equivalent to SomeAttr = RESULT.SomeAttr myAttr5 = theirAttr1 * theirAttr6 # Shorthand way of copying attributes with the same names WITH self.theRealThing COMPUTE foo,bar,baz You would put this in a script inside a rack in your "bridge" specialist. You would set up the rack to be "non-persistent" and use "theRealThing" as the existence attribute. Now, when you access the rack, it will create a dummy object and try to look at its "theRealThing" attribute. This will cause the SkinScript to call the other Specialist and attempt retrieval. If it succeeds, theRealThing will equal the object and the Rack will consider the object to exist in the bridge specialist. If it fails, theRealThing will be a non-existent attribute and the Rack's getItem will return None. Let's say it has succeeded. You now have an object with no attributes loaded other than 'id' and 'theRealThing'. You attempt to access attribute SomeAttr. The second SkinScript declaration fires, and computes the values of myAttr1, myAttr2, SomeAttr, and myAttr5, caching them in the DataSkin. Voila. You now have a completely transformed object, in the context of *your* specialist, with *your* attribute names. It has no leftover acquisition context, but of course you had to have permission to access all those attributes on the object and to the specialist you retrieved it from. But here's the real kicker... You determine in *your* rack the precise ZClass it will be implemented as. In effect, you have rewrapped an object's data into another class. Okay, so that works for reads. What about writes? That's a little more complex, as you'll need to write something like: STORE foo,bar USING self.theRealThing.manage_changeProperties(foo=self.foo,bar=self.bar) For whatever combinations of properties are applicable. If the properties are on a sheet, the USING expression gets more complicated. Note, too, that we could have done transformations on the 'id' to look something up, and that we could also have multiple racks, each doing transformations from different Specialists. Now, you may be asking yourself, "This all looks incredibly flexible, but is it efficient?" Hell no, of course not. You are much better off, if you have the option, of specifying to your framework's user the requirements you have for objects in that part of your system. Then, when they are designing their system, they can get the names and features right, and you call *their* specialist for what you need. If they didn't do it the easy way, then it's again *their* responsibility to re-cast your whitebox as a bridge. (Note, by the way, that if the end-user's raw data is coming from something like an SQL database in the first place, then all they have to do is map from SkinScript to SQL, and this is *much* more efficient than mapping Specialist->Rack->Specialist->Rack->SQL, which involves many more layers of object creation, method calls, and security checks.) To put it another way: design your whitebox specialist how you want it. Make it complete, but of course some parts will have to be change
Re: [Zope-dev] Skinscript tutorial. How's it going?
At 06:33 PM 9/29/00 GMT, [EMAIL PROTECTED] wrote: >Just wondering if there is a new time frame. > FWIW, I have begun writing a SkinScript reference document on the ZPatterns Wiki. Lots of sections are just outlines at the moment, but it's already much better than any other available information on SkinScript (like my meanderings on the list and in chats). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Namespace trouble
Martin =?ISO-8859-1?Q?Gr=F6nemeyer?= writes: > if've had little namespace problems with this code-snipped (dtml-method): > > > > > > > > > > This produces an output like this: 0,0,0,0,0,0,... When I execute your code (Zope 2.2.2), I get the expected result. For me, it seems, that you have a variable named "row_index" in "REQUEST.environ" with value "0". According to source documentation (ZPublisher.HTTPRequest), "environ" has precedence over "other" (where ".set" places it definition). Try a different name with a very low change of being already used: e.g. "row_index" --> "xyz123456". Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
Thanks so much for the response... It turns out, I tried the Python Method and it had the same basic problem as the DTML Method... however I've now moved on, using deletageRetrieve to a new thorny issue. ;-) When I get an object from of another specialist it appears that it doies not inherit from my specialist, but from *its* specialist. (e.g., my framework specialist has methods that I want the dataskins to acquire). I've currently got it wrapped like so: def retrieveItem(self, key): """ get an item""" return self.delegateRetrieve(self, None, key=key).__of__(self) I've tried several different combinations of __of__ etc, but none of them seems to allow the dataskin to acquire, for example, standard_html_header from my specialist. Is there any way to enforce acquisition at this level? thanks! -steve > "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes: pje> At 08:00 AM 9/25/00 -0500, Steve Spicklemire wrote: >> So my retrieve item gets called. *unfortunately* it gets >> called without any namespace parameter... so my retrieveItem >> DTML method has no way to acquire a namespace so that it can >> delagate to something else! >> >> So... here is what I did... I defined a method in my Python >> subclass of Specialist.. >> >> class MarketItemManager(ZPatterns.Specialists.Specialist): """A >> Market Item Manager""" >> >> # Specify a name for the item type: >> meta_type='MarketItemManager' >> >> def retrieveItem(self, key): """ get an item""" return >> self.__of__(self).delegateRetrieve(self, None, key=key) >> >> Then I made a DTML method called 'delegateRetrieve' like so: >> >> >> >> this way, my integrator can edit 'delegateRetrieve' to point to >> whatever Specialist he wants to... and I have a Python >> implementation of retrieveItem. >> >> Does this sound OK? Am I working way too hard here? (I feel >> like I am! ;-> ) >> pje> Remember in the code where I have "# XXX DTML check?" That's pje> because I was anticipating your problem, but since I didn't pje> personally need to do what you're doing yet, I didn't pje> implement it. For one thing, I was waiting to see if Zope pje> core method binding would get fixed. Unfortunately, I'm not pje> sure that Zope method binding is going to be available for pje> anything but PythonMethods in 2.3. As of right now, however, pje> you should be able to use a PythonMethod for retrieveItem, pje> rather than a DTML Method, and it should work. pje> In short, even now, delegateRetrieve should not be necessary. pje> You should be able to implement retrieveItem using a pje> PythonMethod or a DTML Document rather than a DTML Method. pje> (I say *should* because I have not tried it personally.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPL HowTo?
We wished to release the new development version of HiperDom under the ZPL, but we figured it wouldn't be that simple, as the license text is all littered with "Digital Creations". Is it just a matter of s/Digital Creations/Hiperlógica/g? Is this even legal? (This message is mostly rethorical, because we already decided to just release it under the MIT-X11 license anyway, but I feel this question should be discussed if people want to release stuff under the ZPL in the future.) []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Skinscript tutorial. How's it going?
Just wondering if there is a new time frame. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why cant i rename an object from an external method
Grrr That works fine. But it annoys me I cant use a standard function to that. I like to use a standard function and use the checking that someone else wrote. old_id = obj.id() new_id = ASPNTools.safetymunge(obj.id()) self = obj.aq_parent ob = obj self._delObject(old_id) if hasattr(ob, 'aq_base'): ob=ob.aq_base ob._setId(new_id) self._setObject(new_id, ob, set_owner=0) Thanks Shane... phew no Perl necessary. - Original Message - From: "Shane Hathaway" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 28, 2000 8:26 PM Subject: Re: [Zope-dev] why cant i rename an object from an external method > Andy McKay wrote: > > > > Heres a treat. I'm trying to write an external method to rename objects. I > > have approx 10,000 to rename so a script would be nice. No problem I > > thought, imitate a forms manage_renameObject and CopySupport.py can do the > > work. > > > > Rename works fine from the web form, but not from a script. > > (ASPNTools.getsomeobjectsfromstring returns a bunch of objects, Ive tried > > replicating this with resolve_url and get different namespace error, could > > this be a clue?). > > I would try using _delObject and _setObject instead. > manage_renameObject() does some security checks that don't apply in your > case. > > Shane > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] mailing list 'noise'
On Fri, 29 Sep 2000, Rik Hoekstra wrote:
> Karl Anderson wrote:
> > I read the 2-10 articles that I'm probably interested in, and miss the
> > 95% which is almost always noise.
>
> The question is why you'd want to receive all this if you don't have to
> (as remarked above).
> As I understood it, the discussion is less about tools and more about
> modes of discussion.
That's my impression, too. In fact, this would make a good case in point
- this is part of a rambling discussion originally about, as best as i can
tell, current wiki deficiencies for interactive discussions ("I feel your
Wiki Pain:-)"). Focus in this thread has moved to merits and deficiencies
of mailling lists for discussions - wiki is no longer the center in this
branch, the zope-dev list was for a bit, and use of gnus for effective
filtering of mailling lists is perfect fair game. I'm glad, though, that
rik brings back in the issue that really concerns me - modes of
discussion. I'm interested in what they serve.
In fact, i'm *really* interested in "turning answers into stories". That
is, not just getting answers to questions, but preserving them in a way
that makes them easy to find when they're next needed - organizing them so
they collectively serve to describe the topic they're about, to make the
topic, as a whole, discoverable. While i think there are many modes of
discussion that can serve this purpose, depending on the application and
collaborative context, i think mailling list discussion threads need more.
They're a step towards that building-together, but fail to organize beyond
that - so the answers they provide are fragmentary glimpses into the topic
at hand.
One key way wiki documents help bind the fragments is by providing more
"fixed points" around which discussions can range. The fixed points
are not immutable - they can evolve - but they're easy to point at, and
provide a definite manifestation of the topic at some stage of its life.
The dev.zope.org proposals site is one example where definite subjects are
at hand. As someone behind the WikiNG proposal, who *wants* to be able to
reap the suggestions and details from a discussion, but knows i won't have
the time for a while to actually concentrate attention on it, i dread
having to collect all the messages, for later review for harvesting.
Furthermore, messages on the mailling list tend to diverge more and
farther from the topic, than they do when placed within the wiki.
What i'd like the best, for now, is to have discussion happen on the
mailling list *when someone wants to feel something out*, *and then
they're responsible for summarizing in the wiki discussion page, if they
have anything to harvest*.
(Sorry if this message is a bit scattered - i think i saw an opportunity
to tie together a lot of thoughts i have on this subject, but not
sufficient time to do so cleanly, so i'm erring on the side of
just-throw-it-in...)
Ken
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Only using ZODB, not Zope Re: New Proposal: PersistentBlob
Hi Greg, Thanks for the pointer. I briefly looked at this Product and the CVSMixin Product as well, but have one requirement that unfortunately I _didn't_ explain clearly in my proposal. I am not using Zope, only the ZODB so a Zope Product will not help me. My first goal with the proposal was to get feedback on if my idea is correct and what implementation problems could occur, i.e. transactions and file locking. My second goal is to inspire someone to implement it and merge it into the official ZODB. I think that the idea has enough merit and could be useful for a large number of applications. We might have the time and need to implement PersistentBlob ourselves, but I can't say for sure now. Thanks all, John Gregor Heine wrote: > > > Hi all, > > > > Yesterday I put up a new proposal on the http://dev.zope.org site that > > documents my vision of PersistentBlob. The main idea is the be able to > > mark blocks of strings (text or binary) content for storage in a file > > system as individual files. (Or blobs in a relation table.) > > > > The two motivations for this are keeping a ZODB FileStorage small and > > exposing blocks of string content to external processes (i.e. full-text > > indexing). > > > > Thanks for taking a look. > > John > > Hi John! > > Have you had a look at the ExtFile Product > (http://www.zope.org/Members/MacGregor/ExtFile)? > It basically does all the things you want to achive with the PersistentBlob > (i.e. storing files externally and making them accessible for external > processes), except that it's not that deeply integrated into the Zope > machinery and stores the files only in the file system and not in an RDBMS > (which nevertheless could be implemented). > > Cheers, Gregor! -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: New Proposal: PersistentBlob
> Hi all, > > Yesterday I put up a new proposal on the http://dev.zope.org site that > documents my vision of PersistentBlob. The main idea is the be able to > mark blocks of strings (text or binary) content for storage in a file > system as individual files. (Or blobs in a relation table.) > > The two motivations for this are keeping a ZODB FileStorage small and > exposing blocks of string content to external processes (i.e. full-text > indexing). > > Thanks for taking a look. > John Hi John! Have you had a look at the ExtFile Product (http://www.zope.org/Members/MacGregor/ExtFile)? It basically does all the things you want to achive with the PersistentBlob (i.e. storing files externally and making them accessible for external processes), except that it's not that deeply integrated into the Zope machinery and stores the files only in the file system and not in an RDBMS (which nevertheless could be implemented). Cheers, Gregor! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Fix for Can't Change Image & File Security Settings in Zope 2.2.x
Hi, You may, like me, have noticed that you can't change security settings on Image and File objects in Zope 2.2.x. This is because the __call__ method of these objects was removed by the appropriate bit of __ac_permissions__ wasn't taken out. The patch in the PS fixes this... cheers, Chris PS: === RCS file: /cvs-repository/Zope2/lib/python/OFS/Image.py,v retrieving revision 1.105.2.12 diff -r1.105.2.12 Image.py 169c169 < 'getContentType', '__call__', '')), --- > 'getContentType', '')), 450c450 < 'getContentType', '__call__', '')), --- > 'getContentType', '')), ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Soft links again
> > On Fri, 29 Sep 2000, Ibañez Palomar Juan David wrote: > > > It would be great if the symbolic link could have a different id than > > the object referenced. But with the __of__ based solution "link.id" is > > always "referenced_object.id". > > > > How this could be done? > > I think you'd need a special kind of wrapper. It would have the > ability to act as if it were the object itself while transparently > overriding specific attributes. I've pondered creating such > a wrapper before, but it crashed so much that I eventually moved on to > easier stuff. :-) > > I think the ability is all there in ExtensionClass, but the details are > quite difficult. > > Shane > If I've understanded it right it means I must go to C risking my mental sanity (1), other possibility would be to redesign/reimplement my app (2). Ummhh... I think I'll try 1, it seems more entertaining :), so wish me luck. thanks, david ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Soft links again
On Fri, 29 Sep 2000, Ibañez Palomar Juan David wrote: > It would be great if the symbolic link could have a different id than > the object referenced. But with the __of__ based solution "link.id" is > always "referenced_object.id". > > How this could be done? I think you'd need a special kind of wrapper. It would have the ability to act as if it were the object itself while transparently overriding specific attributes. I've pondered creating such a wrapper before, but it crashed so much that I eventually moved on to easier stuff. :-) I think the ability is all there in ExtensionClass, but the details are quite difficult. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Soft links again
Hi Shane, and thanks for Symlink, it's a big step towards solve the problem, but remains an issue... It would be great if the symbolic link could have a different id than the object referenced. But with the __of__ based solution "link.id" is always "referenced_object.id". How this could be done? > > Okay, I've posted a proof of concept. Please keep in mind that this > could be dangerous in terms of security, although I've done a couple of > things to make it safer. Also, there's currently a buglet in > acquisition that makes it so that you can only perform the actions on > the symlink which "anonymous" is allowed to do. > > http://www.zope.org/Members/hathawsh/Symlink/index_html > > Shane > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] URL Traversability of non-page objects
Dieter Maurer wrote: > > Chris Withers writes: > > > A **page** is the result of applying presentation to data in the > > > object system. A page is a particular result of a URL when viewed > > > under certain conditions. > > > > I'd like to add to this: > > components used to make up 'page's should not be URL-visible. Why should > > they be? > > (would this raise issues with XML-RPC?) > Because, you want to access them for management purposes (e.g. > change them). Hmmm... tough problem... I wonder how hard it would be for stuff to 'hidden' until you're logged in? ...probably not that hard, at least for basic authentication... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WikiDot
Ken Manheimer wrote: > (I wonder whether having a single quick ref page for structured text, > linked to on every edit form, would go a long way to reducing those > objections. Particularly if the quick ref page is clear and concise.) Not really... the fact that you even need one of those is why it's not really good enough... > > > and intrinsically determined and easily adjustable > > > organization. > > > > 'Easily adjustable' could be difficult... > > I was just referring to the ease of reparenting a page - if this isn't > familiar to you, see the backlinks pages in any zope.org zwiki. OK, the interface is easy, I was thinking of how I'd implement it. ...but now I think abotu that, it shouldn't be too hard either... :-) Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] StructuredText: Best possible :-S
Ken Manheimer wrote: > As i did in my example, by indentation. (This is a primary component of > the "structure" in StructuredText. Maybe we're not being clear enough > about that in our explanations of structured text - i would expect that > not knowing about it could make it much much harder to understand what's > going on, in general, with StructuredText!) Yup :-) This sort of thing is why I don't really like Structrued Text, but it's probably as good as can be done without nice Wysiwig editing on the browser side... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] mailing list 'noise'
Karl Anderson wrote: > > Ken Manheimer <[EMAIL PROTECTED]> writes: > > > > > I dont see this as a problem: You only create a new list when the > > > > traffic for that proposal gets too great for zope-dev. Threading is > > > > good enough before that point. > > > > > > Yes, but zope-dev has a relatively high traffic load... Why should you > > > have to put up with all that 'noise' if you're only interested in posts > > > for your comparatively small discussion? > > > > Yeah - maillists flow by, and not everyone can follow all the traffic all > > the time!! The cool thing about "content-based" mailling lists, where > > people can subscribe to notifications about changes in subthreads, is that > > you just subscribe to the part of the discussion that has your interests!! > > I haven't understood this gripe ever since I started reading mail with > Gnus. Before anyone groans, I'm not sure that Gnus is ready for > general use by anyone who doesn't want to learn elisp - but surely > there's anther reader with these features? most have features a bit/lot/sufficiently like this. They (apparently) do not work for everyone. Moreover,not everyone works the same way. > > The point that I'm trying to make is that a mailing list has all the > strucure needed to keep abreast of an important thread. I don't think > it's perfect when you can't afford to miss a single important article, > but it works great for general lists. as long as you can follow it. But for prolonged and diverging discussions? Not quite IMO/Experience. Or for discussions that you fall into in the middle? And what if you want to follow discussions at different places, with different tools and you depend on a POP Server or differential access (POP/IMAP/Web) to a mailserver? > I read the > 2-10 articles that I'm probably interested in, and miss the 95% which > is almost always noise. The question is why you'd want to receive all this if you don't have to (as remarked above). As I understood it, the discussion is less about tools and more about modes of discussion. Rik ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
