On Thu Jan 22 07:39:44 2009, Remko Tronçon wrote:
> Attached is part of a solution to the (largely unstated) problem.
Apart from the spelling mistakes, I like it so far.
Spellling mistakes? As iff.
> 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.
I'm not sure I follow - surely we can use XEP-0050 here, and just
define an ad-hoc command that has the precise properties we need?
> 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.
Right - if Kev's dynamic priority thing works out (and I think it
should), then misdirected messages should be quite rare - they'd only
happen post "lock on".
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.
I'm intending to formally define the Missing Messages bit within this
XEP, I just wanted to get this much out, to try to avoid the
accusations that I've not made any such proposal.
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?
Good question. I think the answer is probably yes - we have a command
which says "Gimme messages [from X] [and mark 'em read]".
BTW, I keep on reading "intra-jid" as "infra dig" for some bizarre
reason.
Don't ask me why.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
