[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Disconnected clients
James Carlyle wrote:
Many thanks for your reply.
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 came across a reference to this idea in engine.qos.login.callback
which said "Delegated subscribes: it is possible to subscribe for
somebody else to certain messages. This can be handled by logging in
again with the callback addresses of that delegated client (kind of
gift)". This requirement was marked as "CLOSED". Does this mean that
it has been already implemented in the code base? I'm just getting
started with Java.
No, not closed, it is marked as Change Request.
This is the topic i'm going to implement next.
Probably the Change Request is modified to allow
specifing such callbacks on subscribe() as well.
The client can set up subscriptions on behalf of a toaster, but the
toaster must still have a callback address. I was thinking of what
would happen if the toaster could not be called back. Then the single
client acting as a proxy for multiple toasters would need to maintain a
list of toasters and their subscriptions. I wondered about the
correctness of storing a list of first class subscribers in xmlBlaster
server, and a list of second class subscribers (like toasters) in the
toaster proxy xmlBlaster client.
No problem with this approach.
Has anyone experimented with message forwarding, where an xmlBlaster
server instance could be set up to be a subscribed client to another
xmlBlaster server instance?
Then query evaluation could also be
distributed, with the first server doing broad-grained querying and
doing a single callback to a second level of servers, which would do
more specialised querying, and fan out to more clients.
This somehow correlates with our master/slave cluster idea
(see req. engine.replication)
Hope that I'm not asking dumb questions - I'm looking at xmlBlaster in a
scenario where the end clients are very thin.
mailto:ruff at swand.lake.de