We lack a standard for delivering calendaring tools things like meeting requests. For example an E-mail client telling a calendaring tool to store a meeting request, and a calendaring tool telling an E-mail software to transfer meeting updates via a specific E-mail account to the attendees of the meeting.
I know a few projects implement calendaring for mobile devices. Like Dates, gpe-calendar and also a few Qtopia ones too (if you want me to be politically correct by mentioning the project names, then send me some). It would be a little bit silly for me to start creating patches for those implementations just so I can feed them with meeting requests.
A better solution would be a little D-BUS standard for it. An optional tinymail component could then implement supporting that standard for, for example, iCalendar attachments.
I personally wouldn’t really care if an application like Evolution would implement this. It’s not my goal at least. I do care, however, about Qtopia, GPE and Maemo endorsing such a standard for calendaring software. Maybe even get freedesktop.org onboard? Well, my personal goal really is mobile devices. But hey, it probably should have been a desktop standard a long time ago, right?
So the question: are the decision makers on those fronts interested in something like this? And if they are, where do we go from here? I mean, this standard can be typed in a few minutes. Implemented in a day for most calendaring tools and in something like 30 minutes for tinymail.
Let’s get it done?
What would be the benefit to doing this over an adhoc solution, aside from letting people mix & match calendaring and e-mail clients? My instincts say this might be a YAGNI feature.
(http://c2.com/xp/YouArentGonnaNeedIt.html)
My instinct, which is being fed by my development time for tinymail, says that I already need it :). Today, now.
Ad-hoc solutions would mean that, for tinymail, I would have to implement plugins per supported calendaring application. That E-mail clients would have to implement per calendaring application-specific code (#ifdef joy joy, happy happy ad-hoc #else joy more joy wieeeee #endif).
Nobody wants that. It’s a mess. It blocks developers from even thinking about integration. Which results in users not having the integration and features they are asking for,
I just wanted to say I totally agree with you. I’ve started wondering about this sort of stuff some time ago and I’m putting my act together as time permits to try to come up with a specification that I’ll submit to the Portland Project mailing-list regarding a Services Oriented Desktop.
Most of the stuff is on a series of Tomboy notes but as soon as I iron out some wrinkles I’ll publish them at this page: http://yimports.com/~cpinto/ideas/services-oriented-desktop/
DBUS, in my opinion, will certainly play a major role in increasing the Linux desktop polish and integration.
I think this is a great feature: I was looking into this the other day.
For example, I frequently have to organise meetings and most often this is done by email. I email people in lots of different places and not one of them understands vcal attachments or the like. What I want is a way of grabbing plain text from an email and, with a right click option for example, creating a calendar object to send to my calendar. Currently there seems to be no exposure of the API for calendar events in DCOP/DBUS apps for this. i.e. Kontact.
Parsing the plain text should be fun but with libraries like Perl’s data::manip it should be possible.
I got thinking along this line after seeing the plain text event enter text box on Google’s online calendar. Its just what I need but there seems to be nothing in the OSS world implementing a feature like this.
Anyway I think it is interesting and a standard like you propose would open the way for inovation in the area of usability.
Kevin