Talk:Presence Service D-Bus API: Difference between revisions

From OLPC
Jump to navigation Jump to search
(context please!)
No edit summary
Line 1: Line 1:
Well, The presence services are nice, but why don't the presence services also accept clipboard objects? it might be nice to pass a clipped object over to a buddy.
Well, The presence services are nice, but why don't the presence services also accept clipboard objects? it might be nice to pass a clipped object over to a buddy.

== Proposed additions from smcv ==

Patches sent to the mailing list implement:

* signal Buddy.TelepathyHandleAdded(s: tp_conn_name, o: tp_conn_path, u: handle)
** Another Telepathy handle has become associated with the buddy.
** This must only be emitted for non-channel-specific handles.
** tp_conn_name: The bus name at which the Telepathy connection may be found
** tp_conn_path: The object path at which the Telepathy connection may be found
** handle: The handle of type CONTACT, which is not channel-specific, newly associated with the buddy

* signal Buddy.TelepathyHandleRemoved(s: tp_conn_name, o: tp_conn_path, u: handle)
** The opposite of TelepathyHandleAdded, probably emitted because the contact represented by the handle went offline

* method Buddy.GetTelepathyHandles() -> a(sou)
** Return a list of non-channel-specific Telepathy contact handles associated with this Buddy.
** Returns an array of triples (well-known bus name, connection object path, handle)

* method Presence.GetBuddyByTelepathyHandle(s: tp_conn_name, o: tp_conn_path, u: handle) -> o: buddy_path
** Get the buddy corresponding to a Telepathy handle.
** Parameters are as for TelepathyHandleAdded.
** Returns the object-path of a Buddy.
** Raises NotFoundError if the buddy is not found.


== context please! ==
== context please! ==

Revision as of 11:40, 21 May 2007

Well, The presence services are nice, but why don't the presence services also accept clipboard objects? it might be nice to pass a clipped object over to a buddy.

Proposed additions from smcv

Patches sent to the mailing list implement:

  • signal Buddy.TelepathyHandleAdded(s: tp_conn_name, o: tp_conn_path, u: handle)
    • Another Telepathy handle has become associated with the buddy.
    • This must only be emitted for non-channel-specific handles.
    • tp_conn_name: The bus name at which the Telepathy connection may be found
    • tp_conn_path: The object path at which the Telepathy connection may be found
    • handle: The handle of type CONTACT, which is not channel-specific, newly associated with the buddy
  • signal Buddy.TelepathyHandleRemoved(s: tp_conn_name, o: tp_conn_path, u: handle)
    • The opposite of TelepathyHandleAdded, probably emitted because the contact represented by the handle went offline
  • method Buddy.GetTelepathyHandles() -> a(sou)
    • Return a list of non-channel-specific Telepathy contact handles associated with this Buddy.
    • Returns an array of triples (well-known bus name, connection object path, handle)
  • method Presence.GetBuddyByTelepathyHandle(s: tp_conn_name, o: tp_conn_path, u: handle) -> o: buddy_path
    • Get the buddy corresponding to a Telepathy handle.
    • Parameters are as for TelepathyHandleAdded.
    • Returns the object-path of a Buddy.
    • Raises NotFoundError if the buddy is not found.

context please!

Start off with answering:

  • What the heck is this?
  • Does an app developer need to care?
    • If so, why? Simple easy-to-use fullscreen X apps never before needed this bloat.
    • If not, why should an app developer care?
  • What is the minimum requirement to make this problem go away?

Then you can go into the details, preferably explaining exactly what bytes need to be passed to which system calls.