2010/3/30 Pablo Martin <[email protected]> > 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. > > 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. > * 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) > * 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 > > 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. > > 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. >
I've found some data on elgg release 1.8 http://trac.elgg.org/roadmap It looks like it will be 5 months away. I signed up for the elgg community, is anyone a member already? > > 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. > * 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). > * open micro blogging: not supported, but should be easy to build over the > oauth one. > * 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. > * 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. > * 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). > * 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"). > * 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. > * 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). > > 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). > > Greetings > > Pablo > > > > >
