Tuesday 13 November 2007 3:38:32 pm

Thanks Gabriele,

I fully agree that the benefits need to be defined. A major issue with opensocial adoption is that you *must* reinvent the wheel with your applications. Simple applications like 'Show my latest content', 'Show my friends latest content' and variations of can all be done now but with opensocial there is more on offer. For example, an editor can have dynamic friends - their fellow editors and indeed any groups they have access to. Editors may then see what their 'friends' have been doing. If permissions and security become reliable then you can view your editors activities in the context of another social app elsewhere. Perhaps browsers such as Firefox, Flock, Safari and IE will allow such apps as extensions.

OpenSocial has to augment what users do with their content and for that we need good applications to provide value, otherwise they'll move to another social network which matches their persona's better. Perhaps we need to think of the system as a bank account and the open social apps as the reason to 'bank your content with us'.... perhaps not ;)

I'm going to list out as part of my docs shortly a range of users who might want to use OpenSocial. In this way we can start to work out which types of applications are needed.

I'm in the middle of writing an impementation doc which *has* to be accompanied with initial code for it to be of use. Here is a quick summary:

There will be four new classes within the OpenSocial UserGroup - 'OSUser', 'OSFriend', 'OSApplication', 'OSActivity'. 'OSFriend' and 'OSActivity' may not be needed in final version but they are good to have for now.

The focus of developement right now is the OSUser class. This will contain four attributes with datatypes:

- ezuser. identifier: user_account
- ezcFeed. identifier: open_social_api
- ezcFeed. identifier: foaf_fields.
- ezcFeed. identifier: xfn_fields.

ezcFeed is a eZP4 datatype which 'wraps' and uses the eZ Component Feed for its XML handling of the google atom feeds. However, it only goes so far and it actually needs an XSD field in the class for validation purposes. The upshot of using this datatype is allow dynamic changes of the XSD to use more fields. It *should* work :) I'll post more on this soon with examples.

For all this to work the software required includes 'eZP4', 'eZComponents' & PHPUnit.

I'm hoping this is a start to a simple solution for this problem. There are lots of other ways to implement such a solution, and i'm sure my own will evolve... :)

Paul

Tuesday 24 June 2008 8:20:14 am

A small update:

http://projects.ez.no/opensocial/news/shindig

Sign up while you are over there :)

Paul