Update: The previous proposal of implementing a new module was completely revised at the end because I was suggested that most of functionalities already exist in modules: Cobalt and Teleport. I investigated those modules and changed my previous proposal to this one below which is basically upgrade of Cobalt module together with some features I found missing and previously planned to implement with the new module.
Overview: Make layer around Cobalt's storage methods to allow adding of any asynchronous data store (e.g. ajax based calls to server could be used to communicate to some server storage method). Cobalt is a keyboard command launcher similar to Launchy or quicksilver.
Description: Current version of Cobalt module is designed for use with the HTML5 db api and Google Gears (using a wrapper that implements a subset of the HTML5 db api). The lack of html5 support for Database storage in browsers (as stated on this page it is implemented only in Safari 3.1 and iPhone Safari 2.0) makes this module available to many potential users only via google gears. The aim of this project is to abstract away methods that Cobalt uses for local storage of searchable entries, use history, weights, abbreviations, etc. to allow users with browsers that currently don't support html5 to use this valuable module. The next step would be to expand the list of available context entries (commands), possibly with introduction of simple grammar and support for basic commands to some popular modules. For example user could type imce upload and receive immediately window where she can upload an image. If time remains, module could be expanded to use Services as its backend.
Timeline:
- May 24 - June 7 - Get familiar with Cobalt and Teleport (probably we could use some of the code from teleport).
- June 7 - 28 - Make a layer around current db methods. Test the code by changing datasources. Confirm that basic functionality works in the same way as it works with google gears. Early check of possible speed issues by testing with low server response times. If it appears necessary, check for some speed optimizations, caching etc.
- June 28 - July 5 - Code module configuration options. User can configure which storage method will be used, and if he picks ajax storage method he would be required to pick some additional options. Start testing of the code written till now. Test inside various browsers.
- July 5 - July 12 - Test and polish code written till now and submit midterm.
- July 16 - July 23 - Code command showcase for some popular modules (cck, views, imce, gallery,...)
- July 23 - August 3 - Testing. If everything works correctly early in this phase then some ui or skeleton for adding new commands should be developed so that other authors could link context entries for their modules.
- August 3 - August 20 - Testing and polishing everything for the final project submission.
Mentors:
- Hugo Wetterberg,
- Adam Wlodarkiewicz (awlo)
Contact Details (email at minimum): mulana82 at gmail dot com
Difficulty: Easy
Bio : Available at gsoc student proposal.
Comments
Definitely sounds
Definitely sounds interesting.
I doubt there are many willing mentors in GMT+1, but then again it doesn't really matter.
Good luck!
Thanks!
:)
I'm not sure, but I think
I'm not sure, but I think Cobalt does a lot of this.... http://drupal.org/project/cobalt
Yes, that's true. Cobalt has
Yes, that's true. Cobalt has everything specified to be done here and maybe even more. I guess I used wrong keyword set when checking if something like this already exists :)
But, Cobalt works only on Safari, and Firefox 3 (if user has Google gears installed).
I think this can be done with plain javascript and ajax, and by using e.g. cookies or something else for caching stuff at the client side so this solution could be more general. Of course, I guess a lot of code from Cobalt could be used (especially configuration) or maybe this project could be Cobalt's light version that supports all browsers.
Google is kind of abandoning
Google is kind of abandoning Gears and migrating to using HTML 5. Gears is also a pain in some of the newer versions of Firefox (or at least was). So if the current D7 version isn't migrating away from using Gears, than its definitely needed.
If this is the case, maybe your proposal could be to make this migration to HTML/javascript happen.
Hi mulana and
Hi mulana and linclarc,
Cobalt is actually not dependent on Gears. It is designed for use with the HTML5 DB API but I've written a very thin wrapper around Gears to provide a "asynchronous" interface to it's database API.
What would be interesting is to abstract away the storage method for Cobalt and open up for any asynchronous data store (like behind the scenes ajax request). It would also be great if we could migrate the Cobalt APIs to services 3.x, and leverage it as a storage backend, but that might be overkill and the dependency might raise the bar for those who want to install it.
There is a launcher module that takes the ajax-approach: http://drupal.org/project/teleport. Not as much fun, a bit sluggish, and it's missing hotkeys and the concept of actions.
Thanks for your suggestions.
Thanks for your suggestions. My proposal aims to achieve the same as teleport module which seems a little bit abandoned (last release was in Oct, 2008). Nevermind, I'll add another update to my proposal to include introduction to teleport and investigation of issues you mentioned about it.
So, you're not thinking of
So, you're not thinking of making the Cobalt storage support more pluggable instead? So that it can support a AJAX backend, and in the future key value stores, as it looks like that's what the web standards people are converging instead of the (WebKit) SQLite solution.
I thought about this but at
I thought about this but at first it sounded too complicated for me (I wasn't sure if I could do it at all). With your last comment I think I understand what you meant :) and it sounds ok but I am not sure how much work is required for that task? How long would you estimate it to take for a less than year (in)experienced php developer?
Well, I don't think that the
Well, I don't think that the most important factor is your experience with PHP but with JavaScript. Cobalt is almost exclusively written in js and Drupal/PHP is more or less only used as a data provider. It is actually not very Drupal-specific at all, as my intention has been to make a more general library out of it, that could be used for Wordpress, Django et.c.. Although experience with js concepts like closures etc is a plus I don't think it's needed. The task would be to replace all calls to db (like http://github.com/hugowetterberg/cobalt/blob/master/js/cobalt.js#L99) with a call to something like api.deleteEntriesFromCatalog(name). This api object could be created by some factory function that returns a implementation with a SQLite or ajax backend. I definitely think that you should be able to do this within the timeframe of your proposal.
Ana, If you want to go the
Ana,
If you want to go the route that I've described I could mentor it (I've volunteered as a mentor for another project too, but I think that I can get some assistance from my colleagues too if needed). If you want to discuss it I'm on IRC most of the evening.
Cheers
/Hugo
Great, I have a lot more
Great, I have a lot more experience with js than with php. See you at irc.
"Cobalt module is designed
"Cobalt module is designed for use with the HTML5 db api with google gears wrapper around it."
should be
"Cobalt module is designed for use with the HTML5 db api and Google Gears (using a wrapper that implements a subset of the HTML5 db api)"
I've edited the proposal.
I've edited the proposal. Thanks for your suggestion.