[Ipcf] few questions and comments

[Robert McQueen]

Hi Ricardo,

Thanks for your questions. I've updated the TODO list to clarify the
spec where necessary to answer your questions.

Ricardo Kekki wrote:
> 1. In the telepathy API the presences are given as text strings that each
> Connection can define to be unique for the given Connection/Service.
> How is handled the need for internationalization of the applications
> that use the presence? Only way would be to use the numerical strings
> defined in org.freedesktop.Telepathy.Connection.Interface.Presence.
> If so, why use those free text presences values at all?

They are not intended to be shown to the user - a UI would probably have
a mapping of internationalized names for the well-known identifiers
which are listed in the specification. The text names of presences are
just tokens to allow arbitrary presence states to be communicated
between the connection manager and a UI component that has agreed extra
values.

It is perfectly acceptable for a connection manager to advertise the
availability of other states which are not in this list, which the UI
can choose to ignore (perhaps not let the user set them on themselves)
or use the numbers to at least infer some presence implications of these
unknown states (to show the availability of a contact for example).

Our definition of presence is essentially the same as Galago's, so I've
CC'd its author Christian Hammond who might be able to clarify my answer
or help with any further questions.

> 2. What does Presence.RemoveStatus actually do if there is only one active
> status.

If you are on a protocol where you must always have some kind of status
(which is probably most of them), attempting to remove your one
remaining status (eg away) would result in your status changing to the
default status (eg available).

> 3. What all can be a contact in the sense
> Capabilities.GetContactCapabilities
> assumes? Anything you can open a channel to?

Yeah, it's the same concept of a contact as is used elsewhere in the
protocol to identify a remote contact, such as in channel member lists
or invoking Individual channels. The policy as indicated by
Connection.GetMatchFlags must be used when comparing strings returned by
the connection manager with strings in the client (the client library
will provide a per connection comparison function that heeds these). You
are right to ask however, the concept of a contact identifier is a
little poorly defined in the specification.

> 4. It's not that clear what it means that a contact is listened.
> Is there a list of "listened" contacts in the ConnectionManager that is
> replaced on each call to Presence.RequestPresence, or do the user have
> to poll that call every now and then to get updates?
> 
> And is this meant for contacts we are _not_ subscribed to, or the ones
> we _are_ subscribed to? In some protocols it is not possible to get any
> presence data for contacts you are not subscribed to.

There is no list in the connection manager, and it will do no polling on
your behalf. You should always receive presence signals for anybody on
your "subscribed" contact list channel. Depending on the protocol, you
may also receive presence updates for people you are talking to in a
channel. You may attempt to call RequestPresence on any contact, but it
may fail on some protocols where you may only see presence information
to people you have subscribed to.

A reasonable strategy for the UI would be to call RequestPresence when
you display any connection-specific presence for a given user. If it
fails, give up displaying presence for the user unless you get any
signals about them. If the protocol has a subscription list, and the
user is on it, you need do no more. Otherwise you may poll the user's
presence as often as you wish, depending on the network
connectivity/cost/etc. I may implement something along these lines in
the client library.

> 5. When a contact wants to subscribe to us, does that cause a
> Group.MembersChanged call (with one local pending added) to the allow
> list? What if no one is listening to that (or was it MCs responsibility
> again)?

To the "publish" list channel, but yes, they appear as local pending
members on that channel. If nobody is listening for the signal, the user
remains in the local pending list until someone sorts it out. Mission
control probably wants to listen for this, and check if this list has
any members when you connect, and prompt you appropriately.

> 6. Does Connenction.ListChannels() list excisting channels or supported
> channel types? the former I assume.

Existing channel instances.

> 7. Is it necessary to queue the incoming messages in the ConnectionManager
> and the UI to explicitely remove them? Wound't it be enough if the CM
> knows that the message was delivered; if the UI is down, it will get
> probably lost any way.

Yes, because we need to cope with an incoming message causing a channel
to appear, mission control launching eg the IM app to deal with it, and
while this is loading, the message signal being emitted on this channel.
Otherwise, you'd lose messages to this race condition. The idea is that
the UI is implemented in at a few processes (mission control, chat,
voice) so that they don't all need to be loaded all the time.

> Is there some way for the CM to know if the message was delivered
> other than the explicite Ack?

Not that I'm aware of, because the messages are delivered as signals.
This is intentional, so that other applications such as a logger can
pick up and record the messages as they arrive, but choose not to
acknowledge them.

> 8. There seems to be no typing notifications. Those are quite nice and used
> IM feature and adding one interface for them would not be a big thing to
> do.

The interface isn't tricky (although you'd need to decide if typing
notification was per contact per channel, or per contact per
connection), but the implementation is still more work that would need
doing. We've chosen set a simple group of easily-attainable goals for a
basic yet usable IM system, because we're on such a tight schedule. This
fell by the wayside as something we'll consider implementing next year.

> 9. What about MSRP? If SIP instant messaging is done with that, the CM
> would do it, but if e.g. a file is sent over MSRP, the UI would set up a
> StreamedMedia and then create it's own MSRP session? I don't have a
> proposal on what would be the right way to do this, but it should maybe
> be thought a bit.

The streamed media channel is just for doing SDP (or similar) parameters
for streaming media only, no SIP is ever expected to be implemented by
the UIs. File transfer would be done over a file transfer channel type,
which isn't specced out yet for similar reasons of time constraint. The
UI would set up or receive a file transfer channel to do file transfers.

> 10. Who actually sends and recieves the RTP packets? The VoIP engine I would
> assume? The StreamedMedia explanation could be clearer on this matter.

Correct, the VOIP engine. This isn't required to be a seperate process
under the spec, it's just how we've decided to implement it at the
moment. A hypothetical other streaming media client could do the UI and
the media handling in one process.

> 11. How to set self on a group? (ref. Group.GetSelf)

You don't - the connection manager always knows what your identifier
would be if you were in this group. This is for those channels such as a
Jabber MUC where you can set an identifier where you join, and they are
different per channel. On a related note, we're lacking a way to specify
this nickname and the conference server when you join the room, and a
way to change this per-room nickname later. I'm open to suggestions.

> 12. The UI components must perform significant amounts of string
> comparision.
> I see the point of using strings as generic data type, but maybe it
> should be considered if some of the string-based systems could be
> replaced with some numerical values.

A lot of the places where strings are used are done so that by
arrangement, a connection manager and a client can agree extra values
and add functionality which is not (yet) in the spec. There may be some
places where this isn't necessary, but I really don't want a situation
where something that users of the protocol want to be able to extend,
and two people end up choosing the same numeric value to mean different
things - the protocol is designed to be extensible where appropriate,
although of course we will endeavour to update the specification to
follow reality.

> e.g. give all contacts numerical ID and use those instead of an string.
> As all the components probabaly any way need to store a contact list
> locally, they can get the strings from there.

I'll think about this. It would remove a lot of the confusion about
where contact identifiers are valid, and abstract away the confusion of
per-protocol matching rules for contact identifiers. It'd have to be
transient per-connection mapping, because the connection managers have
no stored states, so its more like a contact handle. However, it would
make it significantly harder for a short-lived application to just pick
up and use a connection without interrogating the mapping of IDs to
users quite a bit.

Regards,
Rob