Intro, Concepts & Arguments

[Jeff Waugh <jdub aphid net>]

Hi all,

Time for my introduction I guess. Please be warned, I don't often hold back
on the opinions, and I don't intend them as bait. Please respond to those
sorts of things offlist. :)

I've been web-hacking for some time now, spending most of my energies on
intranet applications and legacy data integration "stuff".

Unfortunately, that means I can't point you all to some of my really neat
hacks, as they should all be very secure behind strong firewalls. :) As a
concession, have a quick peek at <URL: http://linux.conf.au/>, which is a
quick hack I've done whilst organising a Linux conference in Sydney for next
year.

I'm strongly into Gnome, working on Sawfish documentation right now, and
contributing bits and pieces to projects as I can. I've always had my eye on
the websites as something to really dive into.

Enough with the chatter, I'll give you a summary of a few things I've
considered, most of which I'll expand upon in a lengthier proposal soon.


BACK END
--------

I'll admit, these days I'm much more interested in back-end stuff and
information architecture than pretty HTML. At least you can choose your own
technology poison cocktail and work solely with it, instead of dealing with
client incompatibilities. :)

What do I have experience with? PostgreSQL these days, non-free in the
distant past. Various quick 'n' dirty XML hacks. Getting into XSLT, haven't
used it for a major project as yet.

I don't work with MySQL. ;) If it's not a real database, I don't want to
know. Funnily enough, Tim Perdue (respected PHP hacker, so I've heard) has
finally seen the light on this issue. SourceForge is moving to PostgreSQL.

What do I think we should use? LDAP. If you don't know what LDAP is, you
oughta have a read up on it at <URL: http://openldap.org/>, which is a good
Free Software implementation of it.

I don't really have the space to utterly convince you here, but I'll give
some quick points:

 * Replication designed in. Have back-end servers across the planet,
   securely replicating information as it's updated.
 
 * Can you say FAST? How about LOW OVERHEAD?

 * Hierarchical (like XML). SQL databases are all well and good, but they're
   excruciatingly inflexible, and major content changes effect many levels
   of code, regardless of your "well-planned data access objects".
 
 * Proven. LDAP doesn't suck, and it's not some off-the-back-of-a-truck
   technology. It hasn't been used as a backend for too many websites (that
   I've heard of), but is definitely a major keeper of the world's system
   administration information. It's made for big rollouts.
 
There's more I could write, and better detail. This is the place to ask, of
course.


SCRIPTING
---------

Glue. Need glue. Hafta plug all these bits together. I think this will end
up being PHP - not that I'm happy about that - but it ends up being the best
option.

What should we use in an ideal world? Python. Pure Python, none of this Zope
clutter. :) Python is highly maintainable, clear, fast, and mature. There
are countless modules available for it that assist in web publishing.

Using mod_python or mod_snake is infinitely more powerful than page-based
design, and did I mention that there's an XSLT implementation for Python out
there *right now*?

Zope's nice, but there's too much "environment" for me. As my proclivities
for things like mod_python and stdying mod_virgule show, I like hacking
closer to Apache's bare metal, and get worried when stuck high above a big
tangle of "environment" underneath. Just call me a recovering ASP coder.

Ruby. Ruby kicks the pants out of just about everything mentioned here, but
the reason why we shouldn't use it is because you're already wondering what
it is. Pity, Ruby rocks. <URL: http://www.ruby-lang.org/>

Java is an option, and a good one, but let's keep this very Free. :)

PHP then, hey? PHP is the VHS of the web scripting *languages* world. It
came in late, it sucked compared to just about everything else, and the
quality wasn't so good.

It's immature as a language, and it shows. Other languages have had simple
things like error handling, and some have even had clear object models! It's
younger, and has had a smaller developer community than other languages, so
features aren't there, and may not be for some time. It's casual. Casual is
bad.

That said, PHP is good for rapid development, lots of people know it
already, and it's easy to pick up. We'll have more hackers involved if we
use PHP, because they'll know it, and can contribute.

I do a fair amount of my work in PHP, and it's enjoyable to use when I'm not
gnashing my teeth and scalping innocent bystanders because of its foibles.
PHP supports many technologies that we'll need.


INTERNATIONALISATION
--------------------

This is an enormously important aspect of the project, and something we can
do quite easily. For most of the small "interface" text on the site, I'd
recommend gettext:

 * You can use it in PHP directly.

 * It's not a "new thing", it's a standard. People know how it works.

 * We already have translators familiar with the system, and they're
   actively developing tools to increase their output. Translation memory
   software and the like.
 
 * It, translations, and translators can be integrated into the project as
   easily as other Gnome projects. Same system, same infrastructure.
 
Note that I have *not* performance tested gettext in PHP, so it may prove to
be a PITA from that perspective. We'll have to see.


INFORMATION
-----------

I think the basis for all our information will be a detailed applications
list. If you think about it, most of our information hangs off the apps, and
most of the drawcard to a dekstop environment is its apps.

Note that when I say "apps", I should really be saying "projects". Things
such as libglade and GMime are definitely a part of this list.

Obviously, there are other things that don't easily fit into this
hierarchical system, such as documentation, papers, news, yada yada yada.
I'm sure some of those will find a place in a conventional database. Most
other stuff will be in files.

I will expand on the information I think we'd need to store some other time.
That's a Pandora's Box. :)

One comment - I think two modules, one for web content, and one for the "web
application software" will make our life easier. Again, more on that later.



Actually, there's really too much to explain in this part without tripling
the length of the email, so I'll save my writing for something a little more
white paperish. :)

Oh, and some of us are chatting in #webgeeks on irc.gnome.org too if you're
interested. Nothing much, just casual ideas for the moment. :)

- Jeff


-- jdub aphid net ----------------------------- http://lazarus.aphid.net/ --

     "Boys will be boys, hackers will be hackers, geeks will be geeks,      
        and cyberpunks will always just be ravers with Macintoshes."
                        - Monkey Master, Crackmonkey