Since we announced the new Elgg project on Friday, we've had a couple of questions about how and why we're doing it. It seems sensible to try and answer them here. If you have any other questions, feel free to ask them in the comments, and I'll answer them in a later, follow-up post.
Elgg won't ship with any features. Why not?
Elgg 1.0 won't ship with any end-user features; you can think of it as a social application engine that can power all kinds of different sites and applications. In fact, there are three major ways you can use the new Elgg core:
- As a web application in a box, as it always has been.
- As a collection of back-end PHP libraries.
- As a back-end API that you can use as the building blocks of any socially-aware networked application in any language.
By taking out the features and letting you pick and choose exactly what you want, Elgg becomes a much more powerful system. The plugin system, incoming and outgoing APIs, data import/export and documentation are the major features, as well as user handling and social networking logic. Everything else is optional. In fact, we intend to release the core to download before any extra features are even developed.
On the web as a whole, this reflects how applications have evolved. The era of the all-encompassing, unfocused social network has come and gone; Elgg allows you to build systems that are specific to a particular market or audience, with exactly the features you need.
Is this legacy code?
Elgg 1.0 will be completely rewritten from scratch, which means it will run much faster, with a unified internal structure that will simplify building plugins and enhancements.
If you're an Elgg coder, here's a little more detail:
- We're removing the run() function entirely.
- The plugin and event API structure will remain largely unchanged.
- Templating is all new (and of course, you can swap it out if you want to use Smarty or similar), and content is now separated from design.
- There's a new secure controller system, to prevent action at a distance.
- The database functions will change.
Is Elgg built on any kind of framework?
No.
We've tested a bunch of different frameworks, from all-encompassing managers like the Ruby on Rails clone CakePHP to granular libraries like the Zend Framework. None are as fast or as flexible as no framework at all. In this interview with Alex Payne, a Twitter developer, he talks about the performance issues:
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.On the other hand, the initial systems we've built on the Elgg core - UnLtdWorld, for example - run blisteringly fast.
Of course, if you're desperate to run a framework, you can use Elgg as a set of libraries and reference them from there.
What will Elgg's system requirements be?
Elgg will run on the same platform it's always been designed for: a xAMP stack. In fact, although the exact details are still up in the air, it will require a much smaller memory footprint per process. We are, however, tweaking some of the technical specs, and this is what will absolutely be required:
- Any major version of Apache with mod_rewrite
- MySQL 5+
- PHP 5+ (not CGI mode)
The core development team uses a mixture of Linux and Windows machines, so you can expect the system to run on those platforms flawlessly.
When can we expect it?
The initial core release will be in 6-8 weeks. There will be plenty of detail between now and then; keep checking back for more.
Comments
A couple of comments:
Requring php/mysql 5 and apache is a good decision. PHP4 is pretty antiquated, and it's a good time to make the cut-off.
It is pretty neat that curverider is contributing a large chunk of code. There's been a lot of discussion about where elgg should go for removing run();, and its pretty cool that you guys have time to contribute.
I'm assuming that Elgg will be moving back to the company-centric OS model, since it seems (from the comments on the last post) that the core commit team didn't know about this decision until it was announced. It's kind of surprising to have no input for months, and then find a front-page announcement that current elgg is being depreciated.
I'm still not sure why the decision was made to essentially change the nature of Elgg away from a pre-built social network and into a collection of tools / components for making social networks. From the tech support questions we get, it seems that the average user is not very sophisticated as a programmer. One of the main attractions of Elgg is that it's a simple way for a non-programmer to get a sns up. How about compromising by offering 2 versions, a core that is stripped down, and a 'standard' with the basic profile/weblog/files mods. It's already pretty difficult to get Elgg running on all of the non-standard webhosts out there -- doing so with a huge range of different mods, without a standard setup to validate against, seems challenging.
Hi Nathan:
"How about compromising by offering 2 versions, a core that is stripped down, and a 'standard' with the basic profile/weblog/files mods."
The idea is to offer pre-configured versions for people to download. For example; a YouTube like site, or a full blown social network and so on. Therefore, there will be no need for someone without the skills to worry about install the core and then searching for mods to use.
However, as those who are using Elgg with clients will appreciate, increased flexibility is a must to stay competitive, hence this direction.
I'm actually ok with a barebone structure. BUT, for inexperianced users or just regular non geeksters out there the mod repository and method of installation have to be to notch. Basically a plug and play solution.
I think that would be awsome and would weed out people who just windowshop and leave only true users who would have to take time to think about what sort of service they are trying to build, what componentes they require for that service and they would take the time to assemble it (easiest part of the whole thing).
I personally have 3 elgg networks running on a shared host, have no intention of changing, and don't appreciate being 'weeded out'!
I find it is always a good idea to do a quick cost-benefit analysis before making big changes. The costs of migrating to 1.0 will be come clear, but I am not clear on the benefits, specifically to an existing 0.9 site that is happy with the blogging etc setup. Can someone fill me in on this? Maybe it will be faster and easier to add plugins than it is now.
The only other benefits I can see are flexibility etc, which are more relevant to the creation of new sites. I guess that is why Elgg Classic will live on?
>> It's like getting an engine and then building the rest of the car around it with easily addable parts to make your own brand of vehicle.
Which is how Toyota got so popular :-)
(says the Yaris owner)
For, the options of Elgg 1.0 is exactly what we expected... So, everything is really good news!
We appreciate a lot that Elgg become a platform for social network applications and this is exactly what we do need for our projects.
Ou customers expect good performances and a clean slate to begin and version 1.0 will be in a very good position to offer just that.
Hello
I hope it will run with php in cgi, as otherwise I would fall into the 'weeded out' category before I even started, unless I upgraded to a dedicated server or changed hosts - or, of course, did not use Elgg.
I will keep looking here to see if "tentatively" evolves into definitely.
I have very recently installed Elgg 9.0 although not in a live situation and wonder whether I could be offered some advice. There is no immediate time pressure to get things going and an initial core release date of 6-8 weeks is not a problem, but I assume that will not be a stable release and wonder whether to push ahead on Elgg 9.0 on the assumption that migrating/upgrading will be achievable without too many white knuckles in a few months.
Many thanks and best wishes.
I have to second Nathan's comment - why are you dropping Postgres support?
Does MySQL have features that make you monumentally more productive, over using standard SQL?
Do you not have the resources to test two database platforms?
Have you made changes in 1.0 that require much more effort to create using standard SQL?
I can see keeping an app mysql-only if you've deeply embedded mysql-only syntax and it's a monumental amount of work to refactor. But taking a codebase that, for the most part, works with both databases and closing it off to only work with one database is a step backwards.
I guess I'll have to perpetually run 0.9.1 because I'm not installing MySQL just to run elgg. All of my other backend stuff runs on PG.
Yeah, I too can't see the point in dropping postgres support.
This time postgres is not a requirement to me as I'm running my own box, however I would prefer to use postgres for my additional development for a more reliable database. And it means a more standard sql compatible code, which can be easily adapted to other systems also, including oracle.