[Sigia-l] Notification schema?

[Eric Scheid]

On 7/11/03 1:30 PM, "Listera" <listera at rcn.com> wrote:

>>> It's utterly and trivially easy to do that, with a "Delete messages older
>>> than [  ] hours" type of a pref setting.
>> 
>> If the message doesn't exist, it can't be [not] deleted.
> [...]
>> It's an architectural limitation of the RSS concept. There is no
>> intermediary aggregator in the concept, no analog to the POP3 mail server.
> 
> After you join a mail list, like this one, for the first time, do you
> immediately get several thousand messages dating back to the very first
> message ever? Of course not. Your POP3 mail server has NOT been keeping
> messages for you all this time, because the mail list sender didn't know you
> from Adam, until you joined, and couldn't send messages to an address
> unknown. So in that sense your email is absolutely no different.

That's not the scenario I described. If I subscribe to this list, then go
interstate for a week, remaining subscribed, on my return I can retrieve all
the messages I subscribed to previously. I can do this with email
subscriptions, I *cannot* do this with RSS subscriptions, not without
unusual extensions to the architecture.

> Now, my reference to keeping/deleting RSS messages is for the client end.
> The management of message expiry happens at the client end, just as your
> current RSS reader does today. There has been discussions on management
> expiry per user at the server end, but there are the obvious
> overhead/resources/efficiency issues for that solution. You could design a
> remote syncing solution (like Apple does with the new iDisk) if you wanted
> to have mirrored copies of changes from a given RSS source. But for general
> use this is not needed, although, again, trivial in terms of the technology
> that would be involved.

However, like I said:

    If the message doesn't exist, it can't be [not] deleted.

>> ... but you can only do that with RSS sources under your control.
> 
> Right. But that's what I've been talking about for the past few posts: a
> corporate setting where you control both ends. I even suggested that Joe
> could write his own simplex/complex RSS protocol to include whatever
> functionalities needed. That's the beauty of XML.

Firstly, in corporate settings the source of the information is not always
under control of the consumer of that information. That's the hard luck
reality of corporate structures. Secondly, we're no longer talking about RSS
the concept, only RSS the XML format. Theoretically it's possible to get RSS
content delivered via various gateways (RSS source --> HTTP --> FTP --> NNTP
--> SMTP --> HTTP --> RSS reader), but we're no longer talking RSS the
concept.

e.