Difference between revisions of "SoC webservices publishing"

From GeeklogWiki
Jump to: navigation, search
m (Categories)
m (Backlink)
Line 1: Line 1:
 +
<center>(This is an idea page for the [[Google Summer of Code]])</center>
 +
 +
 
== Incentive ==
 
== Incentive ==
  

Revision as of 11:54, 8 March 2007

(This is an idea page for the Google Summer of Code)


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.