Integrating IM applications - OFI

[Matt Rogers]

On Thursday 13 January 2005 05:37 pm, you wrote:
> 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.
>

Which one is that? I don't know of any.

> > 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.
>

IMHO, the above is too specific to a protocol (Gadu-Gadu in this case). That's 
one of the inherent problems with these types of interfaces, they can't be 
protocol specific, unless you define an interface per protocol.

> 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.

(btw, you don't need to CC me, i'm on the xdg list :) )

Matt