Integrating IM applications - OFI

[Marcin Krzyzanowski]

Użytkownik Matt Rogers napisał:
> On Thursday 13 January 2005 10:02 am, Igor Popik wrote:
(...)
> 
> 
> Your proposal is interesting. Some comments:
> 
> General comments:
> 
> You leave out several protocols that the two major IM clients have support 
> for. Those protocols are Yahoo,MSN, and Groupwise, to name a few. I would 
> imagine they would be added to the spec like so:
> 
> Protocol    | URI
> --------------------------
> Yahoo       | yahoo:
> MSN         | msn:
> Groupwise   | groupwise:

you right, but OFI is not a URI standard. There is a room for support 
any protocol defined in application, all have to be done is to return 
information about supported URI's by application, of course we can 
propose some of them but it may depend on IM client. Example if I'll 
write IM for "foo" protocol which handle "foo:" URI then it's fine.. all 
have to be done is report that my app support "foo:" uri. It's theory, 
other way is implementation in for example blowsers but everythink can 
be done.. my foo app can register proper gconf key as well with url 
handler :)


> 
> and we'd probably also have to add more URIs for any additional protocols
> that would need to be supported.
> 
> Also, in all org.freedesktop.im functions, i feel that the following should
> be returned, although i'm not fully aware of how DBUS works, but this seems 
> better, protocol wise. For example:
> 
> RETURN: 
> 	    (DBUS_TYPE_BOOLEAN success = TRUE,
>              DBUS_TYPE_STRING ofiPresence,
> 	     DBUS_TYPE_STRING description,
> 	     DBUS_TYPE_STRING icon_path)
>     OR 
> 	    (DBUS_TYPE_BOOLEAN result) = FALSE
> 
> IOW, there should always be a status code that indicates the success of the 
> operation as the first part of the returned result. Ayways, i could be 
> completely wrong about this, but it just seems better from a protocol
> point of view.

right.

> 
> org.freedesktop.im.getPresence( contactURI ):
> 
> unless it's planned to get status information for yourself, the 'Hidden'
> value in the standard ofi presence strings is pretty pointless since the 
> client you're getting the information from is not going to know if they're 
> 'Hidden'

I know at least one protocol which return me information about hidden 
contacts.

> 
> We should only get one type of status string. While you can be online and 
> away, it makes no sense to send both. All the statuses are pretty much 
> mutually exclusive since Away applies that are one is also online.

The point is to allow freely mix statuses if needed. example : away with 
description but marked as visible for friends only would looks like
"Away","","desc","Private","",""
This data can be received for any status from buddy list and for user 
himself so then other apps can check you current status.

Have to be set/worked out standard set of available key words to 
describe possible flags.


> 
> 
> It's a nice lightweight interface, but i think there's room for things that 
> can and should be added, such as photos/buddy icons and things of that 
> nature, but it's a decent start.

right, We just had to check how our concept will be in your eyes, and 
hope he should work with that more, or leave it.



-- 
Marcin Krzyżanowski