Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] XMPP

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



Back to the top