RE: Persistent storage / forwarding of events

I agree, it's nice to know the source is out there in case any of us
need to muck with it.

I'll take a moment to put in a plug for Python.  Most of the pubsub
apps I write that don't use JavaScript use Python.  It's compilable
into Java bytecodes or Windows dll's/exe's, plus it runs natively
on more than a hundred platforms.  And Python is fun.  And readable.
And... I'll shut up now.

> It sounds like I can get similar functionality using a topic 
> that stores its events persistently. Especially since topics chain 
> together: could I create a persistent "mailbox" topic that, then route 
> the topics I want to receive into that, and then connect my client to 
> the mailbox periodically and slurp up the new events?

Yes.  In fact, this is what most applications we have do.

> Thanks for the examples of retrieving events — is there a way a client 
> on reconnect can say "send me all the events since #_____, which is the 
> last one I have"?

Unfortunately, no.  Because events can expire, and because the PubSub
Server does not guarantee order of delivery, such a reconnection would
have to be done in client library logic that is usually application-specific.
So we'd write code to do this as part of the app that is able to squash
duplicates received before the last connection dropped.  Note that
do_max_age of infinity on the subscription lets a client replay all
the events in the topic so the app should be able to ascertain where
it last left off.

   Adam


-----Original Message-----
From: Jens Alfke [mailto:[email protected]]
Sent: Thursday, October 16, 2003 2:56 PM
To: [email protected]
Subject: Re: [Mod-pubsub-developer] Persistent storage / forwarding of
events



On Oct 16, 2003, at 2:39 PM, Adam Rifkin wrote:

> multihops could use a store-and-forward paradigm at each of the client 
> hops,
> with servers storing as little as possible so they act more like 
> routers and
> less like databases.  If this is something you're interested in 
> working on,
> I say go for it.

I'm actually trying to focus on applications and not get into the 
plumbing too much. (And, uh, I don't speak Python.) But it's nice to 
know the source is out there to muck with if I have to :)

However, it sounds like I can get similar functionality using a topic 
that stores its events persistently. Especially since topics chain 
together: could I create a persistent "mailbox" topic that, then route 
the topics I want to receive into that, and then connect my client to 
the mailbox periodically and slurp up the new events?

Thanks for the examples of retrieving events — is there a way a client 
on reconnect can say "send me all the events since #_____, which is the 
last one I have"?

--Jens


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Mod-pubsub-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mod-pubsub-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php