I am a user of Remember the milk, Google Calendar, and Drupal. This is what I want to propose for my GSoC application, please feel free to comment, I would like to get feedback.
Description
Remember the milk and Google Calendar are two great applications on the 'cloud'. I would like to create a Javascript application to interact with these services taking advantage of their API. This application would allow organizations to display lists of events, and a page for browsing and searching past or upcoming events. The application would also allow for posting new events from the organization website to the 3rd party service.
While this can be an standalone application, I think it would be great to also create a module in order to access to this functionality from drupal.
The drupal user would have to have an account on the 3rd party service, and the authentication credentials would be stored on the drupal database. The application configuration would be managed in drupal as well. Optionally, events can be categorized employing the site/user taxonomies, and integrated with other modules such as views, RSVP, and the Calendar or even the Event module.
Benefits
To Drupal
I know about the Event module, I haven't used it, but I think that my proposal offers some interesting functionality. Firstly, it allows users to integrate with their already existing accounts with the 3r party service, but even if a user doesn't have an account there already, this module would transfer the events management to the 3r party service, including searching, sorting, publishing or sharing the calendar or feeds. On the down side, it would not make possible for the internationalization of the events, at least until the 3rd party service provide such feature, but event pages in the drupal site can be internationalized though.
To the Open Source community
Since this application can be used in standalone mode, it can be used in any website as far as the user is allowed to embed Javascript code. It can easily become an Open Social application, or ported to other open source projects.
Project Details
Prior art
Both Remember the milk and Google Calendar offer an API that can be directly employed to provide this kind of integration. The APIs are not compatible, but the proposed application would include an abstraction layer (API?) for both APIs, and possibly others can be added in the future.
Value
To my knowledge, this hasn't been done before. It may not be seen as offering significantly different functionality than the Event module, but it still provides a different approach, and more options to the final users. Both, Drupal and the 3rd party communities, and any website would be benefited.
Deliverables
There are basically 3 parts of this project:
- The abstraction layer
- The standalone application
- The Drupal module
Comments
Scope
Given the wide user base that the Events module has, I think it would definitely be best to roll this functionality in there if it doesn't exist already unless you have a very good reason not to. I suggest investigating this first. Of course as an addon to Events, this seems like way less than 3 months of work. The APIs to these services are pretty simple.
Reasons
Thanks,
I think there are basically three uses of my proposal: displaying events, creating events, and linking an event defined in a 3rd party service to content. So far, beyond delegating the event management to the 3rd party service, this is not different from what the Event module provides.
However, as far as I understand, the Event module only allow users to display their own (site) events. My proposal would allow for a number of new possibilities:
* Events can be displayed on different sites regardless of their location or whether they are powered by Drupal or not.
* Moreover, if events are shared or marked as public in the 3rd party service, any user can display those events (e.g. a fan can display her superstar gigs and presentations) with search, sort and filter features, and no extra effort.
I don't want to unnecessarily duplicate the functionality of the Event module, that is why my proposal should be able to work with the Event module for users that need the event node type, the RSVP, signup, and event views. But I don't think that a user that only wants to display or work with events hosted in a 3rd party service would need to install the Event module.
The other reason I don't think of this as an add on to the Event module is that I am also proposing it as an standalone javascript widget for any website. I acknowledge this may not be of interest to the Drupal community though.
As for the fact that there is a wide user base of the Event module, well, that doesn't mean that there are no people that would use my proposal if they only had the option to do so.
Edgar Acosta
Edgar Acosta
How would this be
How would this be different/better than iCal, or the FeedAPI, or web services?
If this project was about expanding/improving existing calendaring functionality in Drupal, I could see a stronger rationale for it. However, given that most of these external services both generate and consume iCal feeds, and that the calendar module generates and consumes iCal feeds, I don't see this as a pressing need.
FunnyMonkey
Tools for Teachers
FunnyMonkey
Differences
Thanks,
I've done my homework ;)
iCal: I am assuming that you meant the Date module. I guess the difference here is that the Date module or API does not allow you to interact with the remote service.
The 3rd party APIs, by the way, allow to add functionality beyond the iCal feed generation and comsuption. For instance what I am proposing is to interact with those services from a (Drupal) website, at the same time that the events can be accessed/used in different ways and from websites in different locations (not just a particular site).
FeedAPI: the API provided by the remote services allows you to fetch, submit, and modify events in independence of the feeds. Besides, the search, filtering and sorting is performed at the 3rd party server.
Web services: Let me know if I am wrong, but as far as I understand, the services module is the opposite of what I am proposing. That is, it provides an API for other applications to get a service from your Drupal site. What I want to do is a (Drupal) client application to interact with remote services. The idea of a generic API proposed by sime is not for offering a service, but for allowing any module to interact with the remote services.
Edgar Acosta
Edgar Acosta
rethink?
I tend to use cck date field instead of Events. It would be good to see a generic api for any module to access these remote services. Imagine that your module stored a reference table about all the remote data, any time there was a change to one of the event items then you'd call a hook to allow other modules to respond to it - and if you could also push changes back to the remote service that would be cool.
Thanks, The generic api is
Thanks,
The generic api is exactly what I would like the abstraction layer to provide. But the way you put it sounds great. I think I focused on the Event module because I thought people would see my proposal as a duplication of that module.
Edgar Acosta
Edgar Acosta