Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Presence API review

Hi Scott and everyone,

On 12/11/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Yes.  In order to move this forward, I've created a new plugin:

Is this the right convention? I'd probably use
org.eclipse.ecf.ui.presence myself. I know that Team's convention is, but a provider isn't really the same as an
API. Search has an and an, but I guess the whole core/ui concept might
render this argument invalid.

My best alternative suggestion at this moment is
'add/removeRosterSubscriptionListener' (and associated interface name
IRosterSubscriptionListener...for roster subscription events).

This is longer but sounds better. This is not urgent, of course, so it
can always wait.

> For IPresence itself, maybe its Mode inner class's static
> EXTENDED_AWAY and CHAT Modes can be removed, they don't really seem
> very useful to me personally (isn't "extended away" really the same as
> "away", and what is a "chat" presence?).
Here's the xmpp reference:

Both statuses still seems pretty useless to me. I think they need to
either be javadoc-ed properly or ditched. For EXTENDED_AWAY, perhaps a
new API can be added for indicating the idle time of someone...or not.
I know OSCAR supports this, but I don't know about other protocols, so
maybe it's not worth it. Which kind of makes me wonder just how many
protocols actually have an AWAY/EXTENDED_AWAY split?

Here's the XMPP reference for 'priority':

Doesn't really explain it, but there it is anyway.  I'm not trying to
justify the xmpp decisions here.  I think that some of them are sort of

This one's certainly a little odd. Something about a "For message
stanzas, the server SHOULD deliver the stanza to the highest-priority
available resource (if the resource did not provide a value for the
<priority/> element, the server SHOULD consider it to have provided a
value of zero)." Although it seems a little ridiculous if everyone
started sending high numbers. I think we need to drop this.

> I've never heard of "subjects" for a message before, but
> maybe that's something new in the IM/chatting industry?

It's just from email...i.e. to:, from:, subject:, body:.

Here's the xmpp spec WRT subject:

I'm thinking one way to handle this would be to add to the
IMessageSender interface a method that is something like this

public void sendMessage(IMessage message);

And then providing a number of constructors (or perhaps a factory) for
creating messages with different initialization params...i.e. so that
rarely used parameters like 'subject' are not in ones face.

This sounds like a pretty good idea. Although I'll obviously need some
actual API in front of me to be sure.

> Both methods should probably also be renamed to something simple. addBuddy
> and removeBuddy is short and to the point.

I'm fine with moving and removing the fromID.  I don't want to introduce
'buddy' at the same time as 'roster, rosterentry, etc'.

Sorry, that suggestion kind of came out of the blue. I meant to tie it
in with my latter suggestion of renaming IRosterGroup/IRosterEntry. So
basically, whatever their names may be, if changed, it would be used
accordingly, addRosterEntry/addNewName, whatever it is.

> A minor technicality, but perhaps both roster
> interfaces should be removed to something else (that is preferably
> much shorter). I present two alternatives here with IGroup/IContact
> and IGroup/IBuddy.

Although we could do this, I would be opposed to it unless it was a)
something obviously better/clearer to everyone than roster; and b) not
'buddy'.  So if we can collectively come up with something that is
better here then we can do that, but I haven't seen anything (yet) that
is particularly good.

I know what you mean here, Scott. I agree with B, actually. When I
think about it, the term "buddy" gets a little too close for comfort.
;P I think the 'contact' concept is pretty good and is aligned on
track with what Mylar is looking for with [1]. A is an issue though,
of course. While IGroup and IContact is short and makes sense (to me
and people that use MSN and/or Sametime and probably other protocols),
they are a little bit too generic and may be used in other APIs (I can
see IGroup possibly springing up in lots of places, not just in ECF).
IRosterEntry and IRosterGroup is a little too cumbersome and wordy for
my liking (which is why I suggested the rename), but it does get the
message across in my opinion.

[1] -


Back to the top