ez projects / opensocial / news / opensocial - what we should do

Attention please: Due to restructuring legacy services, the eZ Projects service is going to be discontinued. All the current repositories will be migrated to a new platform. More details will be announced soon.

OpenSocial - What we should do

We have watched as a flurry of articles, blogs, discussions have appeared about OpenSocial since it was launched by Google. Regardless of the politics of discussing Google v Facebook I want to get on and try it out.

My aim for this project is is simply to produce a working implementation of the OpenSocial API within eZ.

I encourage everyone to read the OpenSocial API:

It is very suprising how incomplete it is! As I do presently like Google I fully expect the API to evolve quickly and eventually mature. By then we should be in a very good position to support our users's content across eZ and non-eZ sites.

I would like this first attempt to consist of three distinct phases.

Implement the People API:

Heres the guide. Thats about all there is at present:

There are several implementations available, all of which implement the base API with custom additions.

We need to support the 'social' user. In addition to the standard user_account datatype we must be able to extend to include standard pim attributes, notable media and messages added by the user, geographical information, relations to other people, etc etc ala FOAF and XFN. If the user runs out of toilet paper we need to record it! Joking...

This implies that our 'social_user' has to be heavily loaded with attributes and require a reasonably complicated data structure, alongside a flexible set of dynamic permissions.

I have a few issues with this. I hate heavily loaded classes - they are simply awful to work with and are often difficult to extend. Sure, we can add all Foaf properties, or just a few, or perhaps elements of XFN. Depending on the phase of the moon you may have a useful social_user or you may have to wait a few months until someone extends it for you need.

I have to raise my hand here and admit i don't have an answer to what constitues the perfect 'social_user' which would allow eZ users and applications to forth onto the social world. But i can see the problems and i want to make sure that the first few revolutions for the social_user are on the right track. We will get there.

And to start with i will need a lightly loaded class with the basics as demoed by Google and friends. The default properties are:

  • Name
  • Image Link
  • Profile URL
  • GeoLocation
  • Email
  • IM
  • Address
  • Phone number

A 'feed' module will be created to support the 'people' view. Parameters to this will be the unique 'userID' and an optional 'friends' field. I'm not sure if a contentobject_id or even a remote_id is enough to uniquely identify a user across the internet. For a single system it should be fine.

Support the activities and app interfaces.

This is to be fleshed out.

Containers, containers...

Containers hold the applications in which data will be shown. Not many containers exist today which does make it a little difficult to work out exactly what they are. Existing containers seem to be no more than Google gadgets within iframes. Security also appears to be a hot potato since you are showing untrusted information within your own site...

Although we dont have enough information to work out an implementation i see three possible implementation types:

  • eZ containers sourcing data from the same instance of eZ.
  • Containers in other sites sourcing data from an eZ instance.
  • eZ containers sourcing data from external sources.

Arguably the first two types are the same. If we implement the API's correctly it should not matter where the container lives. The last instance is interesting as we have to allow data from other sites into our eZ instance which has security implications.

Integrations & Applications

Our community has produced a number of contributions with a 'social' element and therefore should be used for this project. For example, media tools such as those involving the google suite, you tube, flvs, flash remoting etc, plus the various ajax/json tools. I believe this will allow eZ to 'run' applications natively instead of opting for iframes through to google gadgets and similar hosts. The data structures with each tool would be utilised by the 'social_user' which will understand how to communicate.

Applications are another matter. I'm a fan of Facebook - its a great system and their developers have produced a fantastic platform. But is there the need for thousands of very similar applications? OpenSocial will give us this of course, unfortunately. On the other hand im pleased to find that LinkedIn is an OpenSocial partner and as such we should begin to see serious applications - hopefully they will be interesting and useful.

Which applications can we provide which are use to other eZ users, other social sites? I've still to work out a good solid reference application which will showcase eZ in this context. I can think of simple applications which are merely views on data but we can do better than that i believe.


I intend for this to be an eZ publish 4 component. Development has to be entirely test driven. The component team has produced a suite of excellent tools which should be used as much as possible for this project.




Log in or create a user account to comment.

Article info