Website framework discussion
I've polluted two threads just recently with this, so I'll start a fresh one before they deviate too much more from their original topics.
(A bit of) background information: currently we use simple PHP scripts for www.inkscape.org, Planet http://www.planetplanet.org/ for planet.inkscape.org and MediaWiki http://mediawiki.org for wiki.inkscape.org. Plans have been underway for moving www.inkscape.org and probably wiki.inkscape.org to Drupal http://drupal.org (and possibly also merging inkscapeforum.com into it as well). However, with the (renewal?) of discussion of an extensions repositoryhttp://wiki.inkscape.org/wiki/index.php/ExtensionsRepository, I suggested Django http://djangoproject.com for the framework to use for it. Then I thought about the migration of www. and wiki. and thought that Django would really be a better solution than Drupal. (Not sure about the forum yet, having looked at it now I think it's probably best kept as it is rather than migrated to anything.)
On Tue, Dec 1, 2009 at 9:02 AM, Chris Mohler <cr33dog@...400...> wrote:
On Mon, Nov 30, 2009 at 12:02 PM, Joshua Facemyer <jfacemyer@...400...> wrote:
On 11/29/2009 10:22 AM, Chris Morgan wrote:
It would take a bit longer than Drupal to get started for just basic content and all (is there anyone else in the community familiar with Django?
Yes and no - I've used Django with Turbogears, but only for playing around/learning. I'll be digging more into it this week during my off time though - it's very nice so far.
Would the extension repo idea be able to be worked into this, then? I mean, I know it would, but would we want to do that?
I spent quite some time yesterday trying to get Django installed on a Sourceforge hosting account - it was not pretty :( In short, it would be messy (install a local Python along with dependencies for Django, then run the whole mess through fcgi - and I'm not entirely sure it's possible after all).
The extension repository is the main thing that I proposed Django for - the main website and wiki were something I thought of a bit later. Our website is currently hosted with OSUOSL and I checked with them and they say Django would be fine to set up and use. (There are Python/Django-friendly hosts and there are the rest of the hosts - most of them. I personally am just about to move my own sites to WebFactionhttp://webfaction.comso that I get decent Django support... and also an added bonus of version control with Bazaar, Mercurial or Git as I feel like it :-) )
And while I'm rambling on - what about trying Turbogears as a
framework? Sourceforge is moving to it (though I doubt that they will be using the default cherrypy server). At any rate, I will be playing around with Django and probably TG this week to prototype the extension repo. Whether or not the extension repo becomes an addon to the main site, I'm happy to help.
I looked at TurboGears as well when evaluating web application frameworks, and I came to the conclusion that TurboGears just wasn't as pretty, fast, efficient or powerful (you may be interested in this benchmark of frameworkshttp://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/; Django is consistently at the top of the Python ones (compare the left-most column of Django with TurboGears, not the other more optimised ones) and at the top or near the top of all of the results. And Drupal is definitely slower than Django.)
On Mon, Nov 30, 2009 at 11:32 PM, Joshua Facemyer <jfacemyer@...400...>wrote:
On 11/29/2009 10:22 AM, Chris Morgan wrote:
It would take a bit longer than Drupal to get started for just basic content and all (is there anyone else in the community familiar with Django?
I don't, but I'd be happy to help where I can.
What needs to be done to set up an initial site and get it into a bzr repo? That way, those who are interested in helping can get familiar with it and possibly start building.
We'll see about that; it should be easy enough. I've been wondering about where we want to have it though; formerly we've had a repository on SourceForge and a post-commit hook (I think, possibly also it was just a regular synchronisation?) to push the content to the OSUOSL server. It seems to me it'd make sense to host the actual repository on the OSUOSL server. Git is installed there, could we use that? Or would we want to put it into a Bazaar repository and thus need to put Bazaar on it if it isn't? Or perhaps there's some other way we could mirror it? Anyone with expert knowledge in this area?
As for content migration, how would this be done (especially considering the wiki)? I assume the content files could easily be parsed to work with Django.
I think this is the biggest thing in Django's favour over Drupal. With Drupal, we'd need to migrate the main site content in quite a messy way, whereas with Django there's no need really to change how it is at all (it's file-based, you can work with that easily in Django). For the Wiki it would have to be turned into HTML for Drupal - and most people in the Inkscape community don't like working in HTML, they find the Wiki format much simpler. With py-wikimarkup http://github.com/dcramer/py-wikimarkup we should be able to continue to use the Wiki *content* as it is; as for the database schema, I have no idea what that's like with MediaWiki; we may be able to work with it as is, we might need to migrate it in some way). Personally I think I'd be a proponent of the following workflow for the wiki.inkscape.org and www.inkscape.org:
- All content is stored in the file-system (this would mean extracting it out of the database, in the case of the Wiki; a database->files script for that would be no harder than a database->database script) - Content can then be updated through two or three methods: - the website - the version control system - possibly also vi (or whatever your preference is) over SSH (probably not the best way of doing it as you'd have to handle committing with the version control)
planet.inkscape.org could be replaced quickly with Feedjackhttp://www.feedjack.org/(or more likely the newer continuation of it django-planet http://github.com/matagus/django-planet). The hardest step would probably be making sure we keep the old content and migrating it.
Long emails like this are always fragmented. I hope you get what you were looking for out of it in the way of information as to what I'm proposing.
Please think and give opinions :-)
Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
On 12/01/2009 05:35 AM, Chris Morgan wrote:
I've polluted two threads just recently with this, so I'll start a fresh one before they deviate too much more from their original topics.
(A bit of) background information: currently we use simple PHP scripts for www.inkscape.org http://www.inkscape.org, Planet http://www.planetplanet.org/ for planet.inkscape.org http://planet.inkscape.org and MediaWiki http://mediawiki.org for wiki.inkscape.org http://wiki.inkscape.org. Plans have been underway for moving www.inkscape.org http://www.inkscape.org and probably wiki.inkscape.org http://wiki.inkscape.org to Drupal http://drupal.org (and possibly also merging inkscapeforum.com http://inkscapeforum.com into it as well). However, with the (renewal?) of discussion of an extensions repository http://wiki.inkscape.org/wiki/index.php/ExtensionsRepository, I suggested Django http://djangoproject.com for the framework to use for it. Then I thought about the migration of www. and wiki. and thought that Django would really be a better solution than Drupal. (Not sure about the forum yet, having looked at it now I think it's probably best kept as it is rather than migrated to anything.)
The main things we need to be sure of (the reasons for switching to a CMS in the first place) are:
- Ease of use for contributors - Ease of maintenance (probably the biggest drawback to Django - it requires some programming knowledge, while Drupal doesn't) - Some ease of styling ability
Can you comment on these things?
I've been wondering about where we want to have it though; formerly we've had a repository on SourceForge and a post-commit hook (I think, possibly also it was just a regular synchronisation?) to push the content to the OSUOSL server. It seems to me it'd make sense to host the actual repository on the OSUOSL server. Git is installed there, could we use that? Or would we want to put it into a Bazaar repository and thus need to put Bazaar on it if it isn't? Or perhaps there's some other way we could mirror it? Anyone with expert knowledge in this area?
I should think it would be simple enough to get a script to pull it from a Bazaar repo. I think it's important to keep all of the Inkscape stuff together, that way people won't have to know and use different VCSes just for Inkscape. Is it possible to get bzr on OSUOSL?
As for content migration, how would this be done (especially considering the wiki)? I assume the content files could easily be parsed to work with Django.I think this is the biggest thing in Django's favour over Drupal. With Drupal, we'd need to migrate the main site content in quite a messy way, whereas with Django there's no need really to change how it is at all (it's file-based, you can work with that easily in Django). For the Wiki it would have to be turned into HTML for Drupal - and most people in the Inkscape community don't like working in HTML, they find the Wiki format much simpler. With py-wikimarkup http://github.com/dcramer/py-wikimarkup we should be able to continue to use the Wiki /content/ as it is; as for the database schema, I have no idea what that's like with MediaWiki; we may be able to work with it as is, we might need to migrate it in some way). Personally I think I'd be a proponent of the following workflow for the wiki.inkscape.org http://wiki.inkscape.org and www.inkscape.org http://www.inkscape.org:
* All content is stored in the file-system (this would mean extracting it out of the database, in the case of the Wiki; a database->files script for that would be no harder than a database->database script)
Right - shouldn't be too difficult...
* Content can then be updated through two or three methods: o the website o the version control system
We'd have to determine which method to use, wouldn't we? Otherwise we'd have two differing sets of data, unless any update by the Django backend would also commit to the repo. Hmm...is that possible?
o possibly also vi (or whatever your preference is) over SSH (probably not the best way of doing it as you'd have to handle committing with the version control)planet.inkscape.org http://planet.inkscape.org could be replaced quickly with Feedjack http://www.feedjack.org/ (or more likely the newer continuation of it django-planet http://github.com/matagus/django-planet). The hardest step would probably be making sure we keep the old content and migrating it.
Long emails like this are always fragmented. I hope you get what you were looking for out of it in the way of information as to what I'm proposing.
Please think and give opinions :-)
I think it sounds fine, so long as we've got people who are able to manage the process. It would be good to have all (or most) of the website content managed by one backend which is really capable of doing it. How do you feel about it? I think you'd be the one to do most of the difficult stuff, unless someone else with appropriate knowledge steps up.
JF
On Tue, Dec 1, 2009 at 9:27 PM, Joshua Facemyer <jfacemyer@...400...> wrote:
The main things we need to be sure of (the reasons for switching to a CMS in the first place) are:
- Ease of use for contributors
Ease of use for contributors is something that I think we'll be able to get better with Django than with Drupal (partly as we decide much more what we want; a framework is generally more flexible than a rigid CMS like Drupal).
- Ease of maintenance (probably the biggest drawback to Django - it requires
some programming knowledge, while Drupal doesn't)
A lot of the maintenance can be just updating a handful of SVN/Mercurial/Git repositories (depending on the version control method used for the Django application, svn and hg seem to be the most common) from time to time, or using easy_install. Whereas with Drupal you've constantly got to be going to the admin system, seeing what there is to update, downloading the files, extracting, taking the site offline, uploading, running the update script, putting the site back online... (yes, I did put a *very* bad slant on Drupal's update process in that :P)
- Some ease of styling ability
The actual styling and template creation is simpler with Django than with Drupal. It's a lot simpler to turn a plain HTML page into a Django template than into a Drupal theme.
I should think it would be simple enough to get a script to pull it from a
Bazaar repo. I think it's important to keep all of the Inkscape stuff together, that way people won't have to know and use different VCSes just for Inkscape. Is it possible to get bzr on OSUOSL?
easy_install bzr (of course it's best to check with OSUOSL to make sure they're happy with that). The server's got Python 2.5.4 which is fine for bzr and django.
* Content can then be updated through two or three methods:
o the website o the version control systemWe'd have to determine which method to use, wouldn't we? Otherwise we'd have two differing sets of data, unless any update by the Django backend would also commit to the repo. Hmm...is that possible?
Why ever would a Django site not be able to commit and push? I've had that in my mind right from the start. Especially as Bazaar is also written in Python which makes it easier (if it were possible).
I think it sounds fine, so long as we've got people who are able to manage the process. It would be good to have all (or most) of the website content managed by one backend which is really capable of doing it. How do you feel about it? I think you'd be the one to do most of the difficult stuff, unless someone else with appropriate knowledge steps up.
I think I could probably manage the process, but I'll have to see how much time I can give to it though. I'll probably slot it in with my own commercial Django project, borrowing bits of code each way when they overlap at all. And it'll all help me with familiarity and experience with Django (which I hadn't ever used three months ago).
I think that the first step should be version control for collaboration, and a basic port of the current functionality of the static file-based site at www.inkscape.org (it's dynamic in that it's PHP, but it's only used as static content really). Should I start working in a subdirectory of https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape_web/trunkwhic... is the current location, or should we get something bizarre set up?
Thanks for your comments and questions.
Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
I'd say get it in Bazaar (that would be distinct from bizarre, btw :) - unless anyone has any objections?
JF
On 12/01/2009 11:29 AM, Chris Morgan wrote:
Should I start working in a subdirectory of https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape_web/trunk which is the current location, or should we get something bizarre set up?
participants (2)
-
Chris Morgan -
Joshua Facemyer