[Standards] Intra-Jid Private State
dave at cridland.net
Thu Jan 22 11:42:43 UTC 2009
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
> > which is lowering it due to use inactivity without looking at
> > clients).
> I like that the private state thingy is independent of the dynamic
> priority approach. Both are interesting solutions in their own
> 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
> how clients might behave. For example, whenever a client detects
> 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
> 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
> 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:
> there be a 'peek message' command (on top of the 'fetch message'
> command), which would allow all clients to display pending messages
> 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
Don't ask me why.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards