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. >
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 > > > > >
