GSoC Idea - XMPP
octolotl at gmail.com
Wed Mar 24 05:47:47 EDT 2010
Am Di 23. Mär 2010 um 10:08 schrieb Nicolas Vérité:
> On Tue, Mar 23, 2010 at 07:49, Mark Doliner <mark at kingant.net> wrote:
> > On Fri, Mar 19, 2010 at 8:07 PM, Joachim Lutz <octolotl at gmail.com>
> > wrote:
> >> Hi there.
> >> My name is Joachim Lutz, I study computer science (Bachelor) at
> >> Saarland University (Germany) and would like to participate at
> >> Google Summer of Code.
> >> I had the idea of extending the current XMPP status handling so
> >> that priorities are more efficient to use. If multiple clients are
> >> online using the same XMPP-account you can use priorities to
> >> control which one of the clients will receive a sent message.
> >> The approach would be as following:
> >> - One can set a basic priority for the account
> >> - Every status has a value which will be added to the base priority
> >> - Status priorities are:
> >> Chatty > Online > Away > Ext. Away > DnD > Invisible >= Offline
> >> - Invisible is specially set
> >> - Online sets the priority to the base priority
> >> Example:
> >> Given a base priority of 30 and 3 stati (chatty, online, offline
> >> and invisble not counted) the assignment of the stati would be as
> >> following:
> >> Chatty: 30 + 1 *10
> >> Online: 30 + 0 *10
> >> Away: 30 + (-1)*10
> >> Ext. Away: 30 + (-2)*10
> >> DnD: 30 + (-3)*10
> >> The value 10 is calculated by the base priority divided by the
> >> amount of stati dynamically assigned (currently: dnd, away and
> >> ext. away).
> >> That's it, basically. This should offer the most flexibility at a
> >> minimum level of complexity (one value to configure).
> >> I'd be happy to see some feedback/comments from you.
> >> Regards
> >> Joachim
> > Hey Joachim. I'm not extremely familiar with the jabber protocol,
> > but I think this is a cool idea. My biggest concern is that I
> > suspect this change alone might not require 10 weeks worth of work,
> > and so may not be appropriate as a stand-alone summer of code
> > project.
> You could also use the Remote controlling of clients:
> Especially the "Change Status" part:
> It is based on Ad-Hoc Commands:
> Basically, XMPP entities exhange remote commands, by using a forms
> exchange mechanism, much like a wizard. When specifically talking
> about remote controlling of clients, a user can control his client at
> home from work, or all his clients from his mobile phone, etc. He can
> not only control the priorities, but also the status, as well as
> message forwarding, and other use cases.
> I think this is very interesting, from a Pidgin/libpurple point of
> view, as well as training for a student!... ;-)
Hi Mark and Nicolas, thanks for your feedback.
XEP-0146 indeed sounds very interesting :)
For remote controlling other clients of the same account i think they
should get an optoinal entry in the buddy list (this would also make it
easier to send messages to them).
Accessing the remote control functions could then work in a similar as
Gajim (wizard) - but with more focus on GNOME Human Interface
At first it checks which remote control features are supported by the
remote client (e.g. change status, forward unread messages,
run-time options, accept file transfer, leave groupchats).
Then you select the desired one and set needed parameters.
Finally the order gets transmitted and executed on the remote client.
More information about the Devel