Re: [ecf-dev] XMPP

[Ali Naddaf <ali.naddaf@xxxxxxxxx>]

Scott,

As usual, thank you very much for your detailed response. I will open a 
couple of enhancement requests to make sure things don't fall through 
the crack and are documented somewhere; and if I can provide any help 
with either defining the requirements, implementing or testing, I am all 
for that.

Just to give you an idea why I am interested in the XMPP provider, let 
me explain in a few words: in my usecases, the parties that want to 
reach each other (i.e. invoke each others' services) are almost always 
NAT'ed behind some routers or some other devices, so they are not 
publicly exposed/accessible. Having a publicly available server such as 
Google's Jabber server is ideal since all those NAT'ed services can 
easily and reliably get in touch with each other without any trouble, 
even though they are NAT'ed. Among other providers that ECF has in its 
bag of tricks, are there any other candidate that can provide the same 
functionality for me to use besides the XMPP provider? And by "the same 
functionality", I mean a relatively easy way of discovering each other 
without me installing any publicly available server, etc.? If so, I am 
open to looking into them as well. Hopefully that helps you understand 
my usecase and my particular interest in the XMPP.

Thanks again,
Ali.


On 5/17/2010 7:20 PM, Scott Lewis wrote:
> 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