[
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:
org.eclipse.ecf.presence.ui.
Is this the right convention? I'd probably use
org.eclipse.ecf.ui.presence myself. I know that Team's convention is
org.eclipse.team.cvs.ui, but a provider isn't really the same as an
API. Search has an org.eclipse.search.core and an
org.eclipse.search.ui, 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:
http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.2.2.2.1
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':
http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.2.2.2.3
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
weird.
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:
http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.4.4
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] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=111218
Regards,
Rem
