Difference between revisions of "SoC webservices publishing"

From GeeklogWiki
Jump to: navigation, search
(Link to preliminary Webservices API documentation)
(Added a note that this has already been implemented)
 
Line 1: Line 1:
<center>(This is an idea page for the [[Google Summer of Code]])</center>
+
This project was implemented in the 2007 Google Summer of Code. The webservices are available since [http://www.geeklog.net/article.php/geeklog-1.5.0 Geeklog 1.5.0]. This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. There is a [[SoC_webservices_revisited|followup project]], though, if you're interested in working on webservices / AtomPub. For more project ideas, please see our [[Google Summer of Code|ideas page]] for a current list of GSoC project ideas.
  
  

Latest revision as of 10:18, 8 February 2009

This project was implemented in the 2007 Google Summer of Code. The webservices are available since Geeklog 1.5.0. This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. There is a followup project, though, if you're interested in working on webservices / AtomPub. For more project ideas, please see our ideas page for a current list of GSoC project ideas.


Incentive

Currently, stories, comments, etc. can only be published through the web forms that Geeklog provides or by writing directly to the database. Neither of which is well-suited for cases like

  • using a desktop application for publishing
  • migrating data to and from other Geeklog installs or other CMS packages

What Geeklog needs is a remotely accessible API that lets other applications talk to Geeklog and let them add, edit, and remove content. While there are cases where you would want to have access to all the data in Geeklog (e.g. user data), for a first step access to stories, comments, and postings / content provided by plugins (e.g. events, static pages, forum posts) would be enough. This would also cover most of the possible use cases right away.


Goals

Provide a remotely accessible API (in other words, a webservice) that gives external applications access to stories and comments and defines an API that can be used by Geeklog plugins to provide access to their data. The API should, of course, be built on Geeklog's permission system.


Details

The first thing to decide would be if a completely new API would be needed or whether an existing API can be implemented instead. The Atom API would come to mind.

Things to consider:

  • Is there anything specific to Geeklog that no other API supports?
  • How easy would it be to build other APIs on top of Geeklog's API?


Use Cases

Here's a list of things people would want to do with the Geeklog Webservices API:

  • Use a desktop client to post stories.
    This may require implementing another API on top of the Geeklog API. There are already a lot of clients available that support protocols such as the old Blogger API, metaWeblog API, MovableType API, ...
    • The blog plugin is an attempt to provide the old Blogger API but it has to be constantly updated to keep up with changes in the plugins it supports.
  • Importing posts from another CMS / weblog package.
    A common problem of new users when switching to Geeklog is how they would get their content from their old CMS package into Geeklog. Geeklog currently doesn't have any import mechanism, so even when the other software does provide an export option, it won't help them get things into Geeklog.
  • Exporting content from Geeklog.
    As much as we may want people to stay with Geeklog, we certainly don't want to lock anyone in. So an export option would be welcome. Again, exporters for various formats could be built on top of the basic export API.


Documentation

Preliminary documentation for the Webservices API (work in progress).