[Standards] Fwd: Minutes 2009-01-21

Remko Tronçon remko at el-tramo.be
Thu Jan 22 07:39:44 UTC 2009


> Attached is part of a solution to the (largely unstated) problem.

Apart from the spelling mistakes, I like it so far.

> 1) A refinement on the remote control ad-hoc commands to send only some
> pending messages. (Not really essential, but might be nice).

Actually, a real protocol (based on ad-hoc RC) will probably be better here.

> 2) A mechanism Kev proposed for raising priority dynamically relative to
> other resources based on user activity (as opposed to current practise,
> which is lowering it due to use inactivity without looking at other
> clients).

Ok.

I like that the private state thingy is independent of the dynamic
priority approach. Both are interesting solutions in their own right,
and complement each other very well.

I guess the third missing part is a XEP that specifies the 'awaiting
messages' profile of intra-jid status formally, and describes hints on
how clients might behave. For example, whenever a client detects user
action (e.g. mouse movement), it automatically fetches the awaiting
messages from other clients and displays them.

There's also the question on whether it makes sense to provide more
intra-jid state for 'awaiting messages'. For example, a remote client
could change the icon of a contact in a roster if it knew there were
messages awaiting for it in another client, and would fetch them when
clicked; this would mean that the intra-jid state could specify
awaiting messages per contact. The (probably better) alternative is
that the client pulls this information if it wants it (which would
move it to the RC protocol). This in turn raises the question: should
there be a 'peek message' command (on top of the 'fetch message'
command), which would allow all clients to display pending messages in
open chat dialogs without owning the message?

cheers,
Remko



More information about the Standards mailing list