[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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