Re: IM2000 Won't Be Worth It

>James Craig Burley <[email protected]> wrote:
>> >The no-subscription model of mailing lists is certainly interesting.
>> >But what does it achieve that cannot be achieved via NNTP today?
>> 
>> Isn't NNTP a push protocol, requiring its subscribers to, essentially,
>> pay for maintaining incoming messages somehow?
>
>No, it's a hybrid. In fact, it seems to me that NNTP offers every
>advantage that IM2000 could possibly offer for mailing lists, and
>more, and only uses software and protocols that are already available
>today.

Cool.  Though, presumably NNTP doesn't offer the concept of private
email to individuals?

>> >Also, how do "subscribers" know when there is new mail to be fetched?
>> 
>> There are at least three fundamentally different models of list
>> handling I can think of that IM2000 cleanly supports:
>
>Yes, but they are all one of two things: the users must poll the
>central server to see if there are new messages, or the central server
>must keep track of a list of subscribers, in which case most of the
>benefits of the "no-subscription" model are gone.

Well, except for one: subscribers can be *notified* about new messages
to the list, without the list manager or subscribers having to pay for
bandwidth to *push* those messages to the subscribers, and without
subscribers having to *store* those messages pending their reading
them or deciding they don't want to read them.

If enough selection criteria can be moved from the recipient, through
his MUA, to a list manager, then some of that savings could be
substantial.  E.g. killfiles, deciding to no longer read messages
pertaining to a given thread.

But that's definitely orthagonal to IM2000, since similar criteria
propagation would help SMTP-stlye delivery as well, though with
different timing.

>> No, but for lists that would be polled by most subscribers only once
>> every few days or so, it can be *very* efficient compared to on-demand
>> push-style delivery a la SMTP.
>
>Why? Each message is still being download (at least)
>once-per-subscriber, so no bandwidth is saved, and resources are
>wasted on "are there any new messages? no. oh." transactions.

Right, if the polling frequency is too high, the benefit is lost.

Still, widespread POP3 and IMAP deployment suggests that, for most
people and the ISPs they use, polling frequency is insufficiently high
to motivate moving them over to hosting SMTP or similar facilities and
using push-style notification.

>The SMTP
>advantages of having to only send a message once per however many
>recipients are subscribed at a single domain are lost (unless we
>propose some sort of cacheing mechanism too).

Yup.  You can get, say, 100 people at a given domain each polling a
given list on their own arbitrary schedule, then retrieving 100
distinct copies of a given message that comes in, versus a
barely-smart-enough list manager (smarter than qmail anyway ;-)
putting all 100 addresses in a single outgoing multi-RCPT delivery via
SMTP.

>Plus if the subscribers
>really are only polling once every several days, they're on average a
>couple of days behind on the list!

With some lists, that's a *feature*.  ;-)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>