CMS

[Brian Rice]

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

On Oct 28, 2006, at 8:30 AM, Tom Novelli wrote:
> On 10/25/06, Brian Rice <water at tunes.org> wrote:
> ....
>> > 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!

It looks like a good start.

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

> Here's the plan:
>
> - 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 )

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

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

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

> 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

-------------- 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/20061029/5e1e5572/PGP.pgp