DBus interface for meeting creation

[David Woodhouse]

As part of a conference protocol plugin for Pidgin (like the one for
Lync), we have the ability to create meetings.

We need to spawn a "new meeting" editor in the client of the user's
choice, pre-populated with meeting dial-in information, conference-
specific attendees, etc.

I've implemented a plugin for Evolution which supports this:

dbus-send --print-reply --dest=im.pidgin.event_editor \
       /im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
       string:"Organizer <***@infradead.org>" \
       string:"Meeting summary" \
       string:"Meeting location" \
       string:"Meeting description" \
       array:string:***@example.org,***@example.org

Right now I'm shipping that Evolution plugin as part of my own code
base, but I think it makes most sense to standardise the DBus API and
split it out. Then it can be implemented in other calendar
applications, and used from other places (like the Lync plugin for
Pidgin, at least).

Does it make sense for this to be a fd.o specification?

[Simon McVittie]

Post by David Woodhouse
We need to spawn a "new meeting" editor in the client of the user's
choice, pre-populated with meeting dial-in information, conference-
specific attendees, etc.

Rather than inventing a small subset of iCalendar encoded into
D-Bus parameters, would it perhaps make sense to implement this as
a MIME-type handler for iCalendar files, or by sending an iCalendar
blob over D-Bus, or by documenting a somewhat lossless transformation
of iCalendar into a D-Bus data structure in the same way that
https://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Info.html
works with a lossless transformation of a vCard?

Post by David Woodhouse
dbus-send --print-reply --dest=im.pidgin.event_editor \
       /im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
       string:"Meeting summary" \
       string:"Meeting location" \
       string:"Meeting description" \

This is (presumably) fine for Lync, but as a standardized protocol I
think you'll need extensibility: if a different protocol has a different
idea of what is in a meeting invitation, then you'll need a way to
include fields that wouldn't have appeared in a Lync meeting invitation.

smcv

[Corentin Noël]

Post by Simon McVittie

Post by David Woodhouse
We need to spawn a "new meeting" editor in the client of the user's
choice, pre-populated with meeting dial-in information, conference-
specific attendees, etc.

Rather than inventing a small subset of iCalendar encoded into
D-Bus parameters, would it perhaps make sense to implement this as
a MIME-type handler for iCalendar files, or by sending an iCalendar
blob over D-Bus, or by documenting a somewhat lossless transformation
of iCalendar into a D-Bus data structure in the same way that
https://telepathy.freedesktop.org/spec/Connection_Interface_Contact_I
nfo.html
works with a lossless transformation of a vCard?

I wonder why is a D-Bus interface even required here. The simplest
solution (and already working one) is to just pass an ical file to the
calendar app with xdg-open.

Post by Simon McVittie

Post by David Woodhouse
dbus-send --print-reply --dest=im.pidgin.event_editor \
/im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
string:"Meeting summary" \
string:"Meeting location" \
string:"Meeting description" \

This is (presumably) fine for Lync, but as a standardized protocol I
think you'll need extensibility: if a different protocol has a
different
idea of what is in a meeting invitation, then you'll need a way to
include fields that wouldn't have appeared in a Lync meeting
invitation.
smcv
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[David Woodhouse]

Post by Corentin Noël
I wonder why is a D-Bus interface even required here. The simplest
solution (and already working one) is to just pass an ical file to the
calendar app with xdg-open.

Yeah... that might work. In fact Milan implemented that for Evolution
when I first started looking at it:
https://bugzilla.gnome.org/show_bug.cgi?id=787418
https://git.gnome.org/browse/evolution/commit/?id=59dad90040

My concern was that I didn't want to just invoke Evolution — users
might be using something different. But of course doing it through
xdg-open resolves that.

The other reason for favouring D-Bus was that if nothing was set up, we
should just display simple text box to the user with the required
information, saying "cut and paste this into your calendar".

But as long as we either get a meaningful exit code from xdg-open, or
perhaps have a lowest-priority handler for it which invokes xmessage or
something nasty, I think that's OK too.

I don't see why it couldn't be done with passing ical files. I'll take
a look... thanks.

[Simon McVittie]

My concern was that I didn't want to just invoke Evolution — users
might be using something different. But of course doing it through
xdg-open resolves that.

If you are using a platform/runtime library like GLib or Qt (presumably
GLib since you mentioned Pidgin), I'd recommend preferring APIs like
g_app_info_launch_default_for_uri_async() or QDesktopServices::openUrl
over xdg-open. They end up doing the same things as xdg-open eventually
(and in the case of Qt might in fact be implemented via xdg-open), but
xdg-open goes through a shell and some desktop environment detection to
get there.

smcv

[Vladimir Kudrya]

_______________________________________________
xdg mailing list
***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

[Bastien Nocera]

Post by David Woodhouse
As part of a conference protocol plugin for Pidgin (like the one for
Lync), we have the ability to create meetings.
We need to spawn a "new meeting" editor in the client of the user's
choice, pre-populated with meeting dial-in information, conference-
specific attendees, etc.
dbus-send --print-reply --dest=im.pidgin.event_editor \
/im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
string:"Meeting summary" \
string:"Meeting location" \
string:"Meeting description" \
Right now I'm shipping that Evolution plugin as part of my own code
base, but I think it makes most sense to standardise the DBus API and
split it out. Then it can be implemented in other calendar
applications, and used from other places (like the Lync plugin for
Pidgin, at least).
Does it make sense for this to be a fd.o specification?

What about passing this as a URI? There might even be an existing, and
probably underused, RFC for it.