Skip to main content

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

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



Back to the top