2010/3/30 Pablo Martin
<address@hidden>
Hi,
On 30/03/10 02:51, Melvin Carvalho wrote:
Elgg is probably the most mature open source (GPL2/MIT)
'framework'. I assume this is compatible with AGPL.
I've looked in more detail at version 1.7 which was launched earlier
this month, and it appears to have two VERY attractive features:
Restful API (New in 1.7)
http://docs.elgg.org/wiki/REST_API
This looks like it should enable server to server communication via
HTTP
What you'd really want to see is the resful api working will with the
MVC Controller, so I can send a request to almost any (for example
user/wall etc.) page, and it will be able to pass it along to the right
handler.
Global Idenitifiers (GUID)
Well they're actually local identifiers but unique to an install,
so combining with the install root, they can become global. But every
object has a global identifier.
http://docs.elgg.org/wiki/GUID
I've reviewed it in more detail and I'm pretty impressed. I think at a
minimum this is a project that much can be copied from. We can take a
lot of the GNUv2 ideas and reuse, I think they've got a hell of a lot
of stuff right. It's not quite as modern a framework as the likes of
symfony, and the FOAFs need work, but there's a lot of work in there
and plugins that would get us quite far quickly.
If we can get a federated social net obeying linked data principles
under AGPL quickly nailed, that can give us more scope to adding fun
stuff like realtime protocols, desktop integration, encryption etc.
Is there a case for branching elgg? Or perhaps beta testing a sample
elgg community for a month or so, and see if there are any roadblocks.
At the lorea project we use elgg (somewhat of an unofficial fork like
what you are proposing) so i can provide some information on that
approach.
Background: We have several (mildly modified) elgg sites, and our goal
is to be able to federate them by using open protocols and standards
(which is why we have several independent sites), also the goal is that
we don't depend on one software and most importantly, that people (us)
can decide where to put their data while still being able to
communicate with other people with different choices, so the protocols
and data are more important for us than the framework itself. The
premise being: if we can get several elgg to talk together, we can
likely get other softwares to talk together -with the only added
problem of diverging models.
Makes sense
About elgg itself. So much as i hate php I have to say i enjoy working
with elgg:
* It has an interesting model system based on entities with properties
and relationships among them, most notably, you never have to think
about the model and allows introspection easily. this makes it really
easy to add types to the system and should make it easy to serialize to
different formats as well or provide algorithmic access.
The base entity model does all the right things, it has a unique id, access control, timestamp etc. the only thing really missing is to make that global on a web scale, rather than global on a silo scale, else you get a neat architecture, but you're more or less confined to one site, by design
* basic social network permission system in place so a thing can be
seen by friends, some group, insiders, public. this is built in so
"normal" queries will never give you something you can't see (ie,
unless you acces the sql directly)
This is a big plus. Although it's done programatically it may be possible to make it more data portable, so that your same permissions can easily be moved to your deskop, mobile device etc.
* nice view system that makes it really easy to customize and extend
through plugins, the proof being that it has a lot of plugins which
basically go well together (at the lorea install we have 67 plugins 35
of which are from the core).
* strong community
Interesting, I've seen a few plugins, and I like the chat a lot. Interested to see how the facebook sync works. A brief browse showed quite a few plugins that seem to drop out of maintanance.
About it being the most mature framework... probably, but i think some
features on crabgrass are more mature, although i'm not sure how much
of a framework crabgrass is (i havent installed it or looked at the
code) or if its more an application.
I havent looked at crabgrass in as much detail as id have liked yet, so that's of course also something worth evaluating, but my impression is that elgg is slightly futher along, right now.
All in all, the framework has some things that needs to be polished,
but they're not so important for us (lorea), and also the elgg people
are doing a very good job at improving the framework. 1.7 solved many
security issues and stabilized a lot, and for 1.8 they want to work on
improving the interface system.
Agree 1.8 looks like an important release. I think the elgg release cadence is quite good. Any timeline?
About protocols and formats it supports (note i dont mean all have to
be supported, but i think they're relevant and we aim to get all
integrated at least in some basic form to test possibilities):
* openid: server and client working, but there are a couple things to
tweak.
I tried this out, it looks pretty good. If you can do openid you can do foaf+ssl. In fact foaf+ssl clients can log in to any openid site.
* oauth: not a feature in itself, but there is a plugin providing "out
of the box" oauth for user plugins (so you can easily make your own
plugin that uses oauth).
A lot of web 2.0 use OAuth so it's a nice thing to have, and you can also secure an API that way. I tend to think of OAuth as the global version of a cookie.
* open micro blogging: not supported, but should be easy to build over
the oauth one.
Another nice feature to have. I think a lot of the 2.0 protocols will eventually be incorporated (Ostatus etc.) not least so that you can connect to today's social nets, and get at your data. It may be the case that you still have 1 or 2 friends not using GNU Social, so you might want to see what they are doing too ... :)
* foaf: like melvin says the views need some work but the basics are
there. no foaf+ssl but the foaf you get will have the information you
have access to.
The foaf isnt bad, we can put it in the profile page as markup (RDFa) I think too.
* xmpp: there is a jabber plugin which does some integration with
ejabberd, but it needs some work. still, it is actually possible to
chat from elgg with other networks -like gmail- which is quite nice but
its not ready for production, also, the contacts are synced (although
not in the best way possible). of course this is only chat; pubsub and
so on lie in the unknown, but once the basic client works a lot of
doors open to experiment with this.
That's also a good feature, but the more realtime oriented folks may possibly find a way to improve things.
* email: integration of forums from elgg with mailing lists (not with
the goal of federating networks, but imo since email is federated the
email support is interesting).
A good thing to support. Invitation by email is a great way to viral (just look at facebook)
* rest: like you say, there is some kind of support but i'm not sure
it's exactly what i'd like (i think it allows plugin to define rest
actions, but i would like more something like a restful data access and
modification api which is "automagic").
I think it allows you to call internal functions using HTTP GET / POST. So that means we work out the interactions internally, and do them over the API. We can start with perhaps friending and private messaging, then seeing how wire posts etc. work. It's either a little or a lot of work depending on how clean the internals are. The GUID seems to be at the center or things.
* psyc: no integration yet, but we're thinking about this too,
possibly trying to migrate the backend from some elgg item to psyc to
see how it feels (since psyc can take care of the backend). also using
it for chat instead of jabber would be ok since psyc already connects
to other networks.
Can be added as a profile field.
* rdf: i dont see any support (other than foaf), but should be easy to
build a full rdf view(rdf views for all entities) based on the generic
object model (as long as you
can keep it arbitrary).
The FOAF support is a good start, I'd an incremental addition of linked data, possibly use case driven, is the way to go on this.
Probably i forgot something... but i hope you get an idea... In my
opinion, elgg is ok, but the protocols i just related are not, because
not everything we need is covered there, and the specifications for the
next steps after we finish implementing the current ones are basically
missing (i hope we can solve that in this ml :)). At the moment i think
the most we can hope is federated "identity" (openid),
chat/rooms/contacts (xmpp/psyc), federated microblogging (omb), email
and the foaf stuff. so, for extending the federation, i would first
implement the protocols that already exist (the "state of the art"),
and then see how to add other kinds (or more) of data to the mixture.
Both the xmpp, psyc, foaf+ssl (rdf+acls), and omb (oauth) approach look
very promising with regards to what can theoretically be done and is
not done yet.
If someone wants to play around with elgg, we have a development
network where we can provide access to the machine and the code
(
https://n-1.artelibredigital.net), also to see how it works in
production (
http://n-1.cc,
http://redesnenred.net,
http://artelibredigital.net -most are spanish networks, but n-1.cc
should be usable in english).
I did try some of these, and I'm experimenting with my own install. Great post, thanks a lot.
Greetings
Pablo