CMS

[Brian Rice]

On Oct 10, 2006, at 6:56 PM, Tom Novelli wrote:

> Hello everyone... Let me just start off by saying I've taken a renewed
> interest in TUNES and software in general... and I finally met up with
> Fare a few weeks ago in Boston and had a good talk about all this,
> which really helped to clear up a few things.

Hey, Tom. It's good that a couple more of us have met, finally. We  
really ought to meet in one place all at once somehow, perhaps for a  
free/cheap existing conference like OSCON. I've wondered sometimes  
how different the project would have been if this had been done long  
ago, in 1996.

> I'm putting together a prototype CMS (Content Management System) to
> replace the static web site, the wiki, and the mailing lists.  It'll
> use wiki-style markup, but I'm designing it with the goal of running a
> web site that's consistent, thoughtful and polished, like the old
> pre-wiki site.  That means editors and moderators, and the tools to
> support them.

Thanks. Do we need to roll a new one? I can understand if it means  
less effort, but it'd be good to know how that is achieved.

> Now, I should clarify what *I* think TUNES is about: The overarching
> goal of TUNES is to make it *practical* and *convenient* for us
> programmers to automate all the mind-numbing repetitive chores we so
> loathe... or in our jargon, "to facilitate metaprogramming".
> Realistically, that means creating a near-universal language and
> making it extremely popular... which requires reaching out to all
> sorts of people who use computers, and guiding them in the right
> direction.  So, I see another role for us, as a trusted source for
> *practical* advice (with an eye toward the ideal.)

That's a fair assessment, like the networked/decentralized version of  
the idea that has been emerging over the last few (dormant) years. I  
like the idea that we may have a place in the practical development  
world even if our far-off goals are not yet tenable.

> Here's a mock-up to demonstrate what I have in mind for the CMS, in
> terms of the structure and layout.  Implementation, style, and exact
> wording can come later.
>
>  http://tom.bespin.org/.tmp/tunes/index.html
>  http://tom.bespin.org/.tmp/tunes/mockup.html
>  http://tom.bespin.org/.tmp/tunes/edit.html
>
> The implementation will be SQL, HTML/CSS/Javascript, and anything but
> PHP.  It's got to be clean, maintainable, fairly stable, and not too
> obscure.  I'm curious about Ruby... does anyone have enough experience
> to weigh in?  If in doubt I'll use Python or LISP.

Python has Plone, based on Zope, but it is heavyweight, at 40MB per  
instance, and difficult to start up. I have a friend who just exited  
the Zope/Plone hosting business (was imeme.com/imeme.net) and wasn't  
a fan of it after the first few months.

Squeak has Pier which is a CMS based on Seaside. Working with it  
remotely requires using Squeak's VNC server or else its form of a  
socket-based REPL/workspace, but that's not exactly simple. Seaside  
also puts a Smalltalk IDE into the admin interface, which is cool but  
not trivial to work with.

Common Lisp has UCW (Uncommon Web) which is component-based and  
therefore suitable for a CMS but it's not a CMS itself. I just had  
some experiments done in it (hacking together a competitor for an  
existing web-2.0 site) using the UCW-boxset tarball for ease-of- 
installation purposes, and it's pretty good. There are also plenty of  
free AJAX toolkits (prototype, dojo, yahoo's) that can be tied to web  
apps with not too much effort - very few are actually strongly bound  
to a particular server API.

I don't know about Scheme web app servers or CMS's. Ruby obviously  
has Rails but there's no CMS based on it.

Perhaps Factor would be a decent candidate? (lisp/forth dialect with  
a decent compiler and a tiny continuation-based web server)

Finally, most of the arguments for PHP are that: someone else is  
writing/maintaining your CMS for you, so you only have to customize  
or tweak/fix. Unless we really need special features, I'd suggest  
doing a quick shopping tour of the popular ones in PHP that get good  
reviews as far as maintainability, extensibility, and web-usability.

> As for the actual content, I suggest we archive all the old stuff and
> start fresh.  Let's lay down the ground rules... #1: Focus on general
> techniques, and refer to places like Lambda-the-Ultimate and Wikipedia
> for details on specific languages and implementations and such.  #2:
> Focus on original content and *internal* organization.  Don't
> plagiarize; summarize.  #3: ...

Yes, I think we could gain a lot by letting others make our points  
for us, rhetorically and educationally, and just focussing on our own  
messages that build on others'. There are now lots of ways to get  
another site to manage lists of research papers for us, mainly  
CiteULike (via making a TUNES account that members can access, or  
using a tag like "TUNES project"). I don't have more ground rules to  
add yet, but I'll think on it.

> If you need to refresh your memory:
>  http://lists.tunes.org/archives/tunes/2006-August/thread.html#3990
>  http://lists.tunes.org/archives/tunes/2005-October/thread.html#3948
>  http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/TUNES_ 
> %28second_nomination%29

I hadn't noticed the Wikipedia deletion. That's kind of sad that  
people still classify us only as a vapourware project when we're a  
perfectly acceptable visionary documentation site.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/tunes/attachments/20061010/ad9fd61c/PGP.pgp