[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Ali,
Ali Naddaf wrote:
Hi Scott.
I finally got the whole communication work. Here are a couple of
questions that I have: for me to get things to work, I had to
orchestrate the timing carefully; it seems that at the time that I am
creating the adapter (for remote service) on the client side, it
checks for the services that are exposed and not when it is trying to
get the reference to the remote services. In other words, I need to
make sure that the "server" has published the service for that client
before creating the adapter on the client side.
Unfortunately, this is currently true. The reason for this is that
creating the adapter actually initializes the
RegistrySharedObject...which is responsible for handling the reception
and caching of remote service registrations and is the actual
implementation of the IRemoteServiceContainerAdapter.
This is done lazily so that when the xmpp provider (and other providers)
*don't* need support for remote services it won't be burdened with the
extra memory cost of the remote services registry (represented by an
instance of RegistrySharedObject). Of course you have found that the
consequence of this is that when you need it to be greedily created, the
lazy instantiation can mess things up.
It might make a valid enhancement to the xmpp provider to allow the
greedy/early creation of the RegistrySharedObject (which implements the
IRemoteServiceContainerAdapter). I haven't thought this through yet,
but it seems like it would be a valid addition. Another option would
be to create a trivial brand new provider...that did greedy
initialization of the RegistrySharedObject. It would be very easy to
implement...essentially just a new container instantiator.
In any event, if this is a feature you would like, please open an
enhancement request/bug to that effect and I/we will get to it as soon
as possible (realistically, unlikely to before Helios release, as we're
in the end game for that release now).
This restriction on timing is not very ideal since given the use case
that I have, both client and server can come on line and go off line
and again come back on line.
Well, if both the host and consumer are initialized as remote service
providers early...e.g. upon container creation...then they should
respond to the registration/unregistration events caused by the client
disconnect/connect from/to the xmpp server.
Another question I have is related to exposing services on the server
side. With the XMPP Provider, I need to have the client's id's when I
want to register my service on the server side. What if at the time
that my server is doing that, some clients are not there yet and later
on they show up, or even new clients get added? I can have a presence
listener to catch any new client that joins in but is it okay if I
have the registration
adapter.registerRemoteService(new String[]{Myservice.class.getName()},
this, props);
in my listener where the properties props has the ID of the new client
that just showed up? In other words, is it ok to invoke the above line
of code multiple times, once per each client, inside my presence
listener.
I don't know. I would need to check the code and it's been some time
since I've looked at this code. I will try to arrange to do so as soon
as I can, but would appreciate a reminder email(s) from you so that I
remember to do this.
The underlying reason for this behavior for XMPP is essentially that
there is no inherent concept of 'group' associated with a normal XMPP IM
connection. That is, it's not at all obvious, for a given remote
service host, who should be the receivers of a remote service
registration...i.e. it can't/shouldn't be *everyone*, and it's not even
obvious that everyone on the buddy list makes sense (although that is an
option that I've thought of before). OTOH, forcing the host to specify
the target receivers is admittedly not ideal. The tough part is
defining an 'appropriate' alternative(s).
It would be possible, however, to provide some provider-specific service
property that allows the client to define the scope of the remote
service consumer access.
Another thought...that I admit I haven't had a chance to think through
so it may be problematic (that's my disclaimer)...is that perhaps the
OSGi 4.2 remote services (with discovery) can/could be used to define
the appropriate scope for clients. The OSGi 4.2 discovery distributes
the meta-data about both container connect target and target client
information for a remote service. But I'm not sure if this will satisfy
this use case or not.
Note also that the xmpp chat room does/should *not* have this same
issue...because the chat room defines a membership context...i.e. a set
of clients that are actually 'in' the chat room. This is not present
for a regular xmpp IM session.
What is a better way to do that?
This is actually the hard question, IMHO. I'm open to ideas.
Finally, for adding an option to enable the auto-reconnect using Smack
3.1 library, I have opened this issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=313028
Ok, thanks. I recognize that the XMPP provider does need some 'love'
WRT remote services and dealing with xmpp-specific issues...like the
defining the scope of remote service registration target consumers...and
hopefully over the next few months with your help we can jointly provide
it (perhaps also with the help of other ECF committers who have
worked/are working with the XMPP provider, like Nuwan Samarasekera,
Harshana Eranga Martin and/or others).
Thanks,
Scott
