Tag Archives: opendd

Posted on
by

It has been a few weeks now since we released Elgg 1.0, and its really gratifying to see that the forums are alive with discussion. People have been busy hacking on it, writing plugins and contributing bugfixes and enhancements back – including translations for French and Spanish already well on the way.

You may have noticed we have been a little bit quiet since the launch. This is because – since we had been in crunch for so long – we decided to just take a step back and let the dust settle from the launch and focus on some other bits and pieces we wanted to work on.

One of those is of course OpenDD, and I’ve been working on some rather fun demos and some (hopefully interesting!) technologies. Some of the other guys have been working on some other cool stuff – including our liveshouts project which is getting a fair amount of attention.

Now we are looking towards the Elgg 1.1 release and addressing some of the issues which have come up in discussion, including a few core enhancements. Pete has also developed some absolutely fantastic looking themes (which will show how easy it is to drastically change Elgg!)

We are also looking at working on the infrastructure a bit – including some more documentation and guides to writing plugins and customising the look and feel.  We also really want to work on ways to help make community contributions easier.

So, a lot of work ahead… but it should be worth it!

Posted on
by

Federated networks are the future for social networks. Realistically, nobody is going to come along any time soon to challenge the big players like Facebook. But what we can do is allow users to move themselves and their data seamlessly between niche networks, or better yet provide a way of linking up users and data between networks.

There are technologies around that are all working on bits of the puzzle; OpenID, OAuth etc. I think OpenDD solves a key part of the problem by providing a way to link between and move arbitrary data about in a generic and easily understandable way.

In my last post I illustrated the syndication usecase for OpenDD; how you can subscribe to a feed for a user and get a list of their activity in the form of a river. One important thing that I forgot to mention of course is there is absolutely no reason why you couldn’t use the same technique to subscribe to and receive updates about any resource.

Another powerful use case for OpenDD is its use in a live push context, and that is what I’m going to write a bit about today. Now we have already touched on the fact that OpenDD components are all atomic; they do not require a great deal of context or state around them, so for example if you establish a relationship between two entities you do not need to include the complete description of the entities in question – just the relationship.

In the latest specifications I have introduced the concept of being able to unset and remove things, so as well as creating a relationship it is also possible to remove it. This turns OpenDD into quite a powerful tool in your arsenal.

If you take Elgg as an example, Elgg has an events system which we have touched on in previous articles and as well as providing a syndication of an events log in the form of a river, we can also look at pushing those events as they happen out to interesting parties as a sequence of OpenDD components.

So, for example, you could request to be notified when a user joins a group or when something changes on a file (or indeed any other resource) and this can then be pushed out to you in a way that is simple to understand – and again, because we have the concept of an UUID, it isn’t necessary to have the complete context in order for the message to be useful. Everything else can be worked out.

So, using OpenDD, it is now possible to subscribe to users and resources on different networks and receive a feed of updates, but it is also now possible to push messages between networks in an open way that is understood by both platforms.

One of the cool things you can do with that is for example Sharing. In one network you could create a resource, for example a photo of you at a party or a URL you were interested in. Then you could select between the friends on the network you are in but also from friends elsewhere to share the resource with.

The user on the foreign network would then receive an OpenDD push update message saying that you have created a resource and have shared it with them (or rather the platform would receive and interpret it), and because users and the resource are all addressed by UUID the user would be able to see this seamlessly on their own network.

Posted on
by

You are probably all aware of the concept of the River in terms of social networking platforms; being able to see what your friends have been up to as a list of events – what they have been doing, who they have made their friend etc.

This feature – made popular by the facebook “mini-feed” – has become one of the things that users expect from any platform they use and is rather compelling.

What if you want to see what they have been doing on other networks? Would it not be a pretty neat thing to be able to subscribe to their activity in order to receive updates about what they have been up to in a similar way as you would be able to subscribe to their blog via RSS?

This turns out to be a simple yet powerful use case for OpenDD, and this is how we’re doing it in the new version of Elgg.

I talked a bit about how the river was implemented in Elgg 1.0 in previous articles. In a nutshell we have a system log which stores events as they happen in terms of a simple relationship, e.g. “User X CREATED BlogPost”, “User X UPDATED profile”, etc.

Once you have that information it becomes very easy to mine that for extra information and turn it into a River event. Essentially, a plugin would create a view on the specific event and entity and then be able to render it as a river item and provide new views on existing data.

If you remember, I also talked about how I changed the river code to use this thing called ElggRiverStatement, which lets you construct the river in a much more linguistic way and also provides all the information needed by the river views.

Creating a “Friends activity elsewhere” syndication view becomes quite easy. Essentially, all you need to do is export the system log for a user, which you can do very easily using OpenDD as a sequence of OpenDD Relationships. This is because “User X CREATED BlogPost” can be thought of in terms of a relationship.

Once this is done, an aggregation client can retrieve the feeds of all the friends that you’ve signed up to and then sort the relationships by published data, and then – because everything has a UUID – you can then drill down and pull the extra information required – details about the user who initiated the action, the object the event was performed on, metadata etc.

This essentially means you can construct a succession of ElggRiverStatement objects out of an OpenDD feed. This is quite cool, because it means you can take those objects and inject them into the already existing river views and get a river entry back. This means that for absolutely zero extra work, every plugin has the ability to render a “Friend elsewhere” event… and it becomes seamless!

Additionally, you can look to digging further and getting extra information about the entities involved and actually be able to see the entity in question – whether by linking to the entity elsewhere or using the information you have about it to render it locally.

This is quite a simple example, but it shows some of the power of OpenDD. Additionally, I should point out that since OpenDD is atomic, you don’t ever have to get all the information in one go!