[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Ali,
Scott Lewis wrote:
<stuff deleted>
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.
I looked at this for just a moment, and discovered that I've already
implemented the use of a service property that allows the host to
specify a *set* of remote service target IDs. Specifically, the code
looks at the value of the following service property:
org.eclipse.ecf.remoteservice.Constants.SERVICE_REGISTRATION_TARGETS =
"ecf.rsvc.reg.targets";
If the type of the value is ID, that targetID is added to the set of
receivers. If the type of the value of this service property is ID[],
then all the array elements are added to the set of receivers. You
should be able to define the set of receivers upon host/server remote
service registration this way. I guess I wasn't completely out to lunch
when I did this originally (or maybe I was...I can't decide :).
This may provide you with what you are looking for. Still not
ideal...perhaps...but we can discuss other alternatives as we go forward
with supporting your use case.
Thanks,
Scott
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
