XMPP.send proposes me to connect (pop-up) when I connected with XMPP.open

[Jehan]

In the API: XMPP, I want to use the XMPP.open instead of XMPP.up because I need to send a home-made presence (with negative priority being sent to the server and with a specific Resource Application Priority, XEP-0168, as well as Entity Capabilities, XEP-0115).

XMPP.open "works", but unfortunately it seems the rest of the library does not consider me to be connected. So when I execute XMPP.send to send my specific presence stanza with this account, it pops up a dialog window with a list of the available accounts (and the one I use is not even in this list. Anyway Sameplace is deactivated, I use only xmpp4moz).

So instead I must use "XMPP.up" and immediately after connection, I send a new presence stanza to override the previous one. It works well but this is not good because if ever I am not connected with another client elsewhere and that there are offline messages for instance, they will be sent to my extension just after XMPP.up (and before the new presence). Hence as my plugin is not done at all for chating, the offline messages will be lost, unprocessed.

[Massimiliano Mirra (bard-hyperstruct)]

This does not affect current HEAD (http://github.com/bard/sameplace and http://github.com/bard/xmpp4moz) where XMPP.up() no longer takes care of requesting roster and sending initial presence, and responsibility is delegated to client code instead.

[Jehan (jehan-launchpad)]

Nice! Thanks.

[Massimiliano Mirra (bard-hyperstruct)]

Note that this isn't final, there are gray areas. For example, what happens when both SamePlace and another extension are installed and try to go online with different initial presences?

I'm considering merging SamePlace and xmpp4moz anyway (unless addons.mozilla.org finally starts allowing package bundles), so it may be a moot point, but still.

[Jehan (jehan-launchpad)]

Hum... I must say this would be very annoying. I like sameplace and use it quite often (I switch clients depending on the computer). Still I don't want to force people to use it while they use my plugin. So I really prefer to have the library separated from the client. I hope you won't do the choice of merging. Separate development was a very good design choice in my own opinion. Moreover I think you will get less feedbacks (like mine), won't you?

For information my plugin was about getting bookmarks through XMPP (XEP-0048). Cf. http://jabberforum.org/showthread.php?t=1203

[Massimiliano Mirra (bard-hyperstruct)]

I believe that keeping the library in its own package is the right choice from a design point of view, and I'm not going to change that without due thought first. Unfortunately it's a case where real-world concerns (misunderstandings about the separate packages on a.m.o. have been voiced in more than one occasion) make it difficult to stick to pure design.

Note however that merging doesn't necessarily mean that SamePlace will be active, only that it will be part of the package. Most of SamePlace lives in the sidebar, not as an overlay to the browser chrome, and avoiding loading it should be as easy as setting a flag. The bigger downside is those extra 380KB which might not make GPRS users too happy.

I'll bring up both issues (potential conflicts in session establishment and distribution packages) on the mailing list soon.

Interesting extension by the way, I suspect it will make many people happy, especially if you plan on adding synchronization of more data (e.g. sessions). :)

[Massimiliano Mirra (bard-hyperstruct)]

Jehan, what are your extension's requirements for the initial presence? Is it enough for it to be of negative priority or does it need anything else?

I'm again leaning toward having xmpp4moz send it, so that extensions won't step on each others' toes, and leave it to the user to decide whether to receive messages through the account or not. Seems the best compromise (but I'm ready to listen to alternatives).

[Jehan (jehan-launchpad)]

Hi,

no currently I don't send only a negative priority. I have also implemented rap (XEP-0168) and caps (XEP-0115), which change then my initial presence.

But let's be honnest, priority is the most critical part because it makes me lose pontentially the offline messages which should not be directed to my extension. The rest (caps and rap) is more candies that I have implemented because it is nice and are not as critical.
Yet as more and more extension may be willing to implement this, I think your design should be taking this modification of the initial presence stanza into account.

Probably you should calculate yourself the caps's verification string thanks to the features given in createchannel. And for the rap, this should be givable optionnaly in the same time as the global priority (as the rap is simply a feature-specific priority, so it has a similar meaning).

[Massimiliano Mirra (bard-hyperstruct)]

I added caps handling yesterday, I'm implementing negative prio soon and they will get into the repo together. I don't really have a use case for either right now, just adding it for you and Kael, so if you do some testing please let me know how it goes.

[Jehan (jehan-launchpad)]

Nice, thanks!