[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Disconnected clients
James Carlyle wrote:
We have been working on pub/sub mechanisms for RSS (a lightweight XML news
format) news feed distribution for several years and recently started
looking at the pub/sub model for more general XML content. I have just come
across xmlBlaster and sense that it closely fits our problem domain.
I have a couple of questions:
Has anyone built an application which notifies a large number of subscribers
by email or WAP Push?
I haven't done this, but there is no reason why you should not do it.
In my view this scenario is different from the other
clients in that there is no callback intelligence in the WAP browser or
email model, so a proxy for these subscriptions must be built. I took a
look at the code for the xmlBlaster email client, and can see a model for
sending email to several addresses for a single subscription. The
xmlBlaster email client seems to be acting as a proxy for the dumb
Yes.If we use EMAIL or another protocol to blast messages, it doesn't
In the case where 100 email subscribers have 100 different subscriptions,
would it be best to have 100 xmlBlaster email client instances (each
understanding one address and having one subscription), or to have a
separate single email sub-system which understood 100 addresses and had 100
subscriptions to the xmlBlaster server?
Both is possible, i would prefer to have one client.
We are working on a redesigned callback framework, which
allows subscription based callbacks (currently the callback
list is setup as a login qos).
This allows to install subscriptions for others - delegate
the subscription setup because of a toaster, a fridge or an email
client may not be intelligent enough to do it himself.
I hope that my questions make sense - many thanks if you have explored this
area and can offer guidance.
As email support is only a one day hack and nobody coded a WAP plugin
expect to do some coding yourself. Writing a WAP plugin should be
simple and quickly done.
Having these plugins would be a nice xmlBlaster extension,
allowing simple connection of stateless frontend protocols
to "real time" back end servers over CORBA or RMI (or XmlRpc).
Feel free to post further questions to the xmlBlaster-devel mailing
mailto:ruff at swand.lake.de