Specifications/open-collaboration-services-brainstorming

Brainstorming for new Open Collaboration Services ideas and features.

New resources

Donations (micro-payments, google checkout, ePay, paypal, http://flattr.com/)

Comments (list comments linked to an item, add new comments to items, reply to existing comments)

Ratings (how many people already rated an item? have i rated an item?)

Observations about current API

Current API is not RESTful, is more service oriented. You can note this because it talks about Services, but it should talk about Resources

It duplicates several features already provided by HTTP, such as:

GET /resources

list of resource instances

GET /resources/id

show specific resource

POST /resources

create resource when id is not known

PUT /resources/id

update resource or create resource when id is known

DELETE /resources/id

delete resource

The provider resource

OCS API should be flexible enough to support several web applications, beyond implementation languages and frameworks (*PHP, Ruby on Rails, Django, etc..). The provider resource should be able to describe available resources, so the Desktop application or plasmoid is able to access and manage them.

It also would be interesting if the provider resource could describe other REST services already working, like Identi.ca/Twitter, Flickr/Picassa, Gitorious, etc..

Input / Output formats

The provider should announce which formats it accepts for resources. Examples of formats include iCalendar for Events or hCard/vCard for person profiles

There are currently several open standards that can be reused.

Knowledgebase extension for KDE Forums

See this mail: http://mail.kde.org/pipermail/social-desktop/2010-May/000026.html