CMS

[Tom Novelli]

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.

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.

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

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.

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

Comments welcome...

- Tom


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

[Brian Rice]

Post by Tom Novelli
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.

Post by Tom Novelli
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.

Post by Tom Novelli
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.

Post by Tom Novelli
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.

Post by Tom Novelli
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
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.

Post by Tom Novelli
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

[Tom Novelli]

Post by Brian Rice
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 all for it, and Sara loves to travel... we're getting married in
May, so a trip to Portland in July seems unlikely... maybe our
musician friends can tell us how to do it on a tight budget. When I
find a nice cushy programming job, then it'll be a different matter!

There should be a "travel plans matrix" on the new CMS... People on
one axis, months on the other. I wonder if Google offers such a
service already?

Post by Brian Rice

I'm putting together a prototype CMS (Content Management System) to ....

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.

The hardest part is writing for a wider audience, and the database
design is a bit tricky... the general WWW stuff is pretty
straightforward. Of course I want to study the source code of some
existing CMS's, but in my experience, these things are generally 90%
stuff we don't need, and lacking a few key features.

Post by Brian Rice
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.

Thanks for the capsule reviews... it looks like we may have a winner
here. I've been studying up on Lisp this week, and I finally "get it"
now that I've dealt with Forth, Python, etc. and had that talk with
Fare. If Lisp is so important to TUNES, we should just use it
whenever practical, and Lisp-haters like myself will just have to come
around eventually. I should try to explain in writing what convinced
me, before I forget! Anyway, as if that's not enough, Lisp offers a
stable language and better compilers than those other languages. I
presume that it'll integrate with SQL and AJAX just fine.

I suppose we could use a few *short* PHP scripts here and there, for
expediency's sake, at least in the beginning. We can build the CMS
incrementally... *anything* to make web-page editing convenient would
be nice, at this point.

Post by Brian Rice
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.

But first impressions are important... and our site says "We're just
another OS project that's been dormant for 3 years". It would be a
huge improvement just to show that we're still alive, and to mention
the visionary aspect right up front. In fact, we should -- I mean,
I'll volunteer to -- do it *this month*, as soon as I get enough input
on the wording.

But anyway, it's time to put the past behind us!

- Tom

[Brian Rice]

Post by Tom Novelli

Post by Brian Rice
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.

Thanks for the capsule reviews... it looks like we may have a winner
here. I've been studying up on Lisp this week, and I finally "get it"
now that I've dealt with Forth, Python, etc. and had that talk with
Fare. If Lisp is so important to TUNES, we should just use it
whenever practical, and Lisp-haters like myself will just have to come
around eventually. I should try to explain in writing what convinced
me, before I forget! Anyway, as if that's not enough, Lisp offers a
stable language and better compilers than those other languages. I
presume that it'll integrate with SQL and AJAX just fine.

CLSQL: http://clsql.b9.com/ which has a SQL query lisp-language and
nice O-R mapper, comparable with Ruby-on-Rails' ActiveRecord but more
configurable and macro-izable... for PostGreSQL there is an
additional utility that just takes existing tables and makes suitable
classes for them, wrapping over foreign key relations automatically.
I recommend only building the version of clsql that is specific to
the database implementation you choose, as the full package goes
through the process of trying to build bindings for every database it
supports.

CL-AJAX: http://www.cliki.net/cl-ajax which I haven't tried but looks
suitable.

There is also http://www.cliki.net/JavaScript which has some
interesting links.

Post by Tom Novelli
I suppose we could use a few *short* PHP scripts here and there, for
expediency's sake, at least in the beginning. We can build the CMS
incrementally... *anything* to make web-page editing convenient would
be nice, at this point.

TiddlyWiki ( http://www.tiddlywiki.com/ ) was brought up at last
night's local Lisp user group meeting and is notable that it is
entirely done in JavaScript, and basically the server interaction is
minimal, in terms of a basic "check this out" and "upload" API. I'm
playing with it and am somewhat impressed so far. I don't know if
it's even remotely useful for the kind of thing we need, but I like
that it pushes the imagination a bit.

Post by Tom Novelli

Post by Brian Rice
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.

But first impressions are important... and our site says "We're just
another OS project that's been dormant for 3 years". It would be a
huge improvement just to show that we're still alive, and to mention
the visionary aspect right up front. In fact, we should -- I mean,
I'll volunteer to -- do it *this month*, as soon as I get enough input
on the wording.

Sorry, maybe this was intended as a specific request for input on the
wording... I suggest you just start trying to do it, and
incrementally get feedback. The worst that happens is that the good
PR we get for trying to do the site is tarnished just slightly by
exposing some of our editing process.

Post by Tom Novelli
But anyway, it's time to put the past behind us!

Indeed.

--
-Brian
http://briantrice.com

[Tom Novelli]

On 10/25/06, Brian Rice <***@tunes.org> wrote:
....

Post by Brian Rice

Post by Tom Novelli
I'll volunteer to -- do it *this month*, as soon as I get enough input
on the wording.

Sorry, maybe this was intended as a specific request for input on the
wording... I suggest you just start trying to do it, and
incrementally get feedback. The worst that happens is that the good
PR we get for trying to do the site is tarnished just slightly by
exposing some of our editing process.

Ok, I've gone and changed the front page... the month is over and
nobody has complained. I backed up /serv/tunes/tunes/ this morning,
in preparation for some major clean-up... I'll just start chopping...
if I get carried away, just let me know and I'll fix it!

At the last minute I remembered the website is maintained by CVS, and
rebuilt every midnight.... It's an arcane system but it works, and
it's not so bad for me now that I finally have broadband internet. I
suppose we should keep it until we have a replacement ready...?

Here's the plan:

- Pinch some Wiki formatting code from Cliki and a JS wiki; adapt to
make them match; rewrite later.

- Set up a simple web-based editing system... (Enter a password, edit
pages like a wiki, stored as text files... Convert to HTML upon
saving.) Write new material in this "wiki" format... adapt the format
as needed.

- Design a database to *organize* the content in a fairly fine-grained
way, with robust security, versioning, cross-referencing, etc.


I have CMUCL, SBCL, UCW, MySQL, CLSQL and CL-AJAX sitting here;
hopefully I'll get into the web/db stuff this weekend. I think I've
learned enough Lisp by now.

My initial impression of Common Lisp is that it's over-complicated and
it doesn't have as nice a codebase as Python because it's not as
popular (although guys like Fare are working hard to change that).
Still, Lisp seems like the Right Thing (tm) in the long run. Ideally,
I think, we'd design a cleaner dialect of Lisp for use as an
all-purpose intermediate language, and implement CL, Slate, Python,
ECMAscript, etc. on top of that. I prefer Python's syntax. The nice
thing about CL is, it's mature. Does all this make sense?

- Tom

[Brian Rice]

After some server maintenance and subsequent hiccups, the site is
back online...

Post by Tom Novelli
....

Post by Brian Rice

Post by Tom Novelli
I'll volunteer to -- do it *this month*, as soon as I get enough

input

Post by Tom Novelli
on the wording.

Sorry, maybe this was intended as a specific request for input on the
wording... I suggest you just start trying to do it, and
incrementally get feedback. The worst that happens is that the good
PR we get for trying to do the site is tarnished just slightly by
exposing some of our editing process.

Ok, I've gone and changed the front page... the month is over and
nobody has complained. I backed up /serv/tunes/tunes/ this morning,
in preparation for some major clean-up... I'll just start chopping...
if I get carried away, just let me know and I'll fix it!

It looks like a good start.

Post by Tom Novelli
At the last minute I remembered the website is maintained by CVS, and
rebuilt every midnight.... It's an arcane system but it works, and
it's not so bad for me now that I finally have broadband internet. I
suppose we should keep it until we have a replacement ready...?

Yeah, I suppose, but these days it's pretty easy to move from CVS
into Subversion which supports scripting hooks so that site updates
can merely be driven from commits to a particular release branch. I
can explain this in detail on request but I learned it just from
online SVN documentation... it's not too hard. I personally like
Darcs, but it's overkill in this case, I'd wager.

And we don't need the CVS meta-data line in our web-pages any more...
it doesn't do us any good and looks ugly. Actually, these days the
trendy/more-appropriate thing to do is use <LINK REL=History
href=...> tags in the header to deal with meta-data like version
history, and just have the page itself contain text copy.

Post by Tom Novelli
- Pinch some Wiki formatting code from Cliki and a JS wiki; adapt to
make them match; rewrite later.

Cliki doesn't contain much formatting code - it'll be pretty simple.
These days there's also CL-PPCRE for advanced regexp-y goodness, not
to mention some other equally valid CL text packages: http://
www.cliki.net/text

Here's an example of a particular wiki-ish syntax being re-done in CL:
CL-Markdown: http://common-lisp.net/project/cl-markdown/
(syntax described at http://daringfireball.net/projects/markdown/
syntax )

Post by Tom Novelli
- Set up a simple web-based editing system... (Enter a password, edit
pages like a wiki, stored as text files... Convert to HTML upon
saving.) Write new material in this "wiki" format... adapt the format
as needed.

At a recent local Lisp/functional meeting, someone mentioned http://
www.wikimatrix.org for wiki software feature comparisons. You should
check that out just to see what's well-known and available. There are
quite an interesting number and degree of alternatives.

Post by Tom Novelli
- Design a database to *organize* the content in a fairly fine-grained
way, with robust security, versioning, cross-referencing, etc.

Sure, and there are probably some available CMS database schema that
could be used as a template (although I haven't looked for that in
particular).

Post by Tom Novelli
I have CMUCL, SBCL, UCW, MySQL, CLSQL and CL-AJAX sitting here;
hopefully I'll get into the web/db stuff this weekend. I think I've
learned enough Lisp by now.
My initial impression of Common Lisp is that it's over-complicated and
it doesn't have as nice a codebase as Python because it's not as
popular (although guys like Fare are working hard to change that).

Common Lisp is certainly big and reflects a huge amount of (awkward)
political compromise, and yes it helps to have a big community that
all weigh in and contribute to each other's work to refine the
libraries that people initially start.

That said, CL does allow you to start in a blank package and, say,
create an entirely CLOS-oriented dialect within it. Up to a point,
anyway, after which you need to look into writing a compiler or
partial-evaluator.

Post by Tom Novelli
Still, Lisp seems like the Right Thing (tm) in the long run. Ideally,
I think, we'd design a cleaner dialect of Lisp for use as an
all-purpose intermediate language, and implement CL, Slate, Python,
ECMAscript, etc. on top of that. I prefer Python's syntax. The nice
thing about CL is, it's mature. Does all this make sense?

Python's syntax has been done as a "skin" on lisp in various packages
and I can imagine a future where code is not textual but is
interacted with in a "MVC" style fashion (higher-order tree-
transformation with massively-customizable editing framework, blah
blah blah). So I'd basically say that whatever syntax trees were
edited would be most directly renderable as Lisp, rather than being
Lisp itself. I'm assuming here that you're proposing this text for
website introductory copy, because doing all of this is a Lot Of Work.

--
-Brian
http://briantrice.com

[Tom Novelli]

Post by Brian Rice
After some server maintenance and subsequent hiccups, the site is
back online...

Great, now I can commit the next iteration. It might be too
self-deprecating -- although we deserve it. What do you think?

I looked at those links you sent. Markdown looks decent, but Creole
is very close to what I had in mind, so I'm inclined to hop on that
bandwagon... http://www.wikicreole.org/wiki/AllMarkup

...

Post by Brian Rice

Post by Tom Novelli
Still, Lisp seems like the Right Thing (tm) in the long run. Ideally,
I think, we'd design a cleaner dialect of Lisp for use as an
all-purpose intermediate language, and implement CL, Slate, Python,
ECMAscript, etc. on top of that. I prefer Python's syntax. The nice
thing about CL is, it's mature. Does all this make sense?

Python's syntax has been done as a "skin" on lisp in various packages
and I can imagine a future where code is not textual but is
interacted with in a "MVC" style fashion (higher-order tree-
transformation with massively-customizable editing framework, blah
blah blah). So I'd basically say that whatever syntax trees were
edited would be most directly renderable as Lisp, rather than being
Lisp itself. I'm assuming here that you're proposing this text for
website introductory copy, because doing all of this is a Lot Of Work.

And these syntax trees could be compiled by Lisp, metaprogrammed as
Lisp, etc. In other words we'd use Lisp semantics. I'll try to work
that into the new web pages.

Let me retract what I said about CL being more mature than Python, now
that I've tried installing a few packages... It's definitely something
I want to learn, but I've got my hands full already. If worst comes
to worst, I'll just hack together some Python scripts. For now I'll
focus on the content.. there's plenty of organizing, writing and
rewriting to do.

- Tom

[Brian Rice]

Post by Tom Novelli

Post by Brian Rice
After some server maintenance and subsequent hiccups, the site is
back online...

Great, now I can commit the next iteration. It might be too
self-deprecating -- although we deserve it. What do you think?

It's improving. I think it's good that you removed the language about
"giving up on" writing an OS which is not strictly true, it's just a
different priority simply because of practicality and the culture of
this generation.

Post by Tom Novelli
I looked at those links you sent. Markdown looks decent, but Creole
is very close to what I had in mind, so I'm inclined to hop on that
bandwagon... http://www.wikicreole.org/wiki/AllMarkup

Okay, so that's in the same family as Mediawiki's markup so should
not be hard to transition to and learn (which seems to be the point).

Post by Tom Novelli
...

Post by Brian Rice

Post by Tom Novelli
Still, Lisp seems like the Right Thing (tm) in the long run.

Ideally,

Post by Tom Novelli
I think, we'd design a cleaner dialect of Lisp for use as an
all-purpose intermediate language, and implement CL, Slate, Python,
ECMAscript, etc. on top of that. I prefer Python's syntax. The

nice

Post by Tom Novelli
thing about CL is, it's mature. Does all this make sense?

Python's syntax has been done as a "skin" on lisp in various packages
and I can imagine a future where code is not textual but is
interacted with in a "MVC" style fashion (higher-order tree-
transformation with massively-customizable editing framework, blah
blah blah). So I'd basically say that whatever syntax trees were
edited would be most directly renderable as Lisp, rather than being
Lisp itself. I'm assuming here that you're proposing this text for
website introductory copy, because doing all of this is a Lot Of Work.

And these syntax trees could be compiled by Lisp, metaprogrammed as
Lisp, etc. In other words we'd use Lisp semantics. I'll try to work
that into the new web pages.

I think you should think/present it as "the semantics that e.g. Lisp
has" rather than identifying it as Lisp's semantics, since the
semantics of having state, proper closures, and first-class functions
are really all you're probably interested in, or rather more
specifically there are nuances of CL or Scheme that don't matter so
much to us if we differ a bit in order to accommodate the multiple
syntax possibilities. Perhaps there's a better way to phrase it that
gets this point across succinctly.

Post by Tom Novelli
Let me retract what I said about CL being more mature than Python, now
that I've tried installing a few packages... It's definitely something
I want to learn, but I've got my hands full already. If worst comes
to worst, I'll just hack together some Python scripts. For now I'll
focus on the content.. there's plenty of organizing, writing and
rewriting to do.

CL does have an immature packaging cultural practice which is
significant. We're agreed on the last point, to focus on the content.

--
-Brian
http://briantrice.com