Notes from Gnome Summit, Boston, 2006
Thanks to Nathan Holstein for taking the initial notes in the Telepathy BoF!
- People included:
SimonMcVittie, RobTaylor, RaphaƫlSlinckx and later DafyddHarries from Collabora
- Chipx86
- Boyd Timothy, Gary from Novell
RobTaylor gave an overview talk: http://projects.collabora.co.uk/~robot101/telepathy-guadec-2006.odp
- Protocol discussion:
- Ain't gonna get Skype soon...take it up with them
- but it's perfectly possible for them to provide a proprietary binary-only Skype connection manager which would interoperate fine with existing UIs
- Nokia has SIP support in the works, but hasn't been publically released yet
- Ain't gonna get Skype soon...take it up with them
- Interaction with Kopete, ongoing
- Kopete is integrating Telepathy
- Email in telepathy is probably not right.h
- should be at a higher level: Galago?
- Addressbook integration
- EDS, KDE exports info over DBus
- There will be a communication BOF Sunday
- the components are there, but the UI needs to be worked out
- Telepathy, EDS-DBus, Galago everything rolled together with new user abstraction
- what is the distinction between IM/email?
- ooh, he logged off, so send a delayed email instead
this is a UI use case rather than something Telepathy should do automatically! -SimonMcVittie
- ooh, he logged off, so send a delayed email instead
- the components are there, but the UI needs to be worked out
ChipX86 warned that GAIM users keep asking for blog integration and Telepathy users are likely to do the same
- variation of everything is a file... everything is a GAIM plugin!
- sending an IM posts an entry
- all present seemed to agree that this is strange
- ... although Livejournal's Jabber server actually implements this!
- (In the context of whiteboarding) Why have an IM program with half-assed drawing?
- rather have Inkscape with telepathy collaboration
- rethinking the UI
- embedding into the interface
- say, a GTK+ chat widget thats embeddable
- Some want to create a do-it-all interface
- better to add whiteboard code (as library) to individual programs
- it _is_ possible to have a do it all though
- right click in Gaim, click on "collaborate on drawing"
- pervasiveness of collaboration and documents and people
- not an emphasis on programs or a chat program
- pervasiveness of collaboration and documents and people
- What can we do once things are in place?
- Project Soylent
- Collabora's work has been framework and backends
- Gaim UI/backend split nearly complete
- some backends (the ones we don't already have CMs for) could get rolled into telepathy?
- VNC use case
- Go to contact list and invite somebody to give you remote assistance.
- Special interface for invite/accept?
- VNC over p2p UDP?
- Correlating conversations/calls with application data channels
- If I'm collaborating on a drawing with somebody, I don't want to have to switch between drawing window and conversation window -- how to make Telepathy smart enough to correlate the two?
SimonMcVittie handwaved about channels having a parent/child relationship (possibly limited to a 1-level thing, like Unix session IDs/session leaders). RobTaylor thought this was crack and/or out of scope for Telepathy - Telepathy should just encapsulate/model what the underlying IM protocol is doing and this is not a feature IM protocols have.
Concluded that this comes under the heading of task-oriented UI, and is perhaps out of scope for Telepathy. RobTaylor to talk to the Gimme people and find out what they think.
- Reusable Telepathy widgets
- If an application wants the user to select an online contact, they shouldn't have to implement their own widget to do it. Reusable widgets means consistent UI.
- Conferencing
- Voice call conference: it's often useful to have a text channel so you can send URLs to members, or to chat and and ask questions while people are talking. At which level do we unify the different channels?
- What if different components of the communication are happening via
- different protocols? I.e. Alice, Brenda and Carlos are having a voice conference using SIP and they decide to start whiteboarding a document. The SIP CM doesn't have application data channel support. Alice and Brenda have XMPP accounts, but Carlos doesn't.
Even in the ideal case where all the members of the first channel have accounts on the service of the other CM, we rely on something to unify their disparate accounts -- i.e. sip://alice@foo.com == JID alice at bar.org. Does EDS do this for us?
- Logging
- API is not too hard to design -- let's get it done
- Should be a sub-UI service
- Might suck to have multiple implementations with different storage (retrieving logs if code bitrots)
- iChat
- Custom video stuff?
- Nobody seems to be working on this
- Falls under the category of compatibility/weaning people from proprietary systems
- Galago
- Should Galago grow a way of invoking actions on contacts (talk to, call, show logs for, etc.) -- are Gimmi interested in this?
- telepathy-feed needs work
- Exposing capabilities through Galago
- Ekiga
- No dialogue ATM

