Re: [Cscene-discuss] Look and Feel

[ixx <ix...@cs...>]

On Wed, Jan 05, 2000 at 02:30:35AM +0100, Juergen Hermann wrote:
> On Tue, 4 Jan 2000 19:10:56 -0600, ix...@cs... wrote:
> 
> >say we will do that stuff via CVS at souce forge. thats fine... what about
> >adding new articles? and moderating them etc? maybe that is done on at a diff
> >place? thats what i am asking... what are your ideas. 
> 
> This question can only be answered in large parts if we know what
> technology we use for publishing. If it's database-driven (which it
> should be), then adding an article to the database does it. Note that
> "database" could be a text file.

This is what I was wanting.  Just not for mirrors.  The backend and/or main
site.  Then have the ability for static mirroring.

I would be happy to code or provide code I already have for the backend stuff.

> OK, let me outline my thoughts:
> 
> 1. We should use a technology that is batch-enabled, so mirrors work
> like always (copying the static html result) or online (doing the batch
> processing themselves).

great.  this means we do not have to make mirrors change backend stuff just
because we do.

> 2. That batch process can take the CVS repository and process what is
> there in a way that creates the site. That process can involve SQL
> database updates, creation of index lists, applying site layout, etc
> pp.

i do not know how new articles would come in.. direct to cvs?  then editors
play there?  anyhow all sounds good.  dynamic backend and static frontend.

> 3. Candidates for that batch process: Perl/Python scripts, a C++
> program, XML (which would be my favourite). 
> 
> Using XML would make it easy to produce a consistent and easily
> changeable site layout. Only ONE site has to be XML enabled, the result
> can be static HTML. Markup of index keywords is also very easy. XML
> processing can be online or batched.

I have not played with xml much, but i be glad to provide perl coding, and
learn xml on the way :)
 
 
> > what about searching with mirrors... 
> 
> Either they point to cscene or install the necessary stuff. Like you
> yourself already outlined...

probably the easiest would be to search via the main cscene site and rewrite
the urls appropriately.

> >3. mailing lists.
>
> I think the cscene READER lists should be on cscene, the PROJECT lists
> on sourceforge.

sounds good.

> >4. new issues.
> >
> >how should issues be released? instant from CVS? every 24 hours? every 2 weeks?
> 
> Should we HAVE issues? :))
> 
> I think we should have article states (NEW, INREVIEW, ACKNOWLEDGED,
> PUBLISHED). The change from ACKNOWLEDGED --> PUBLISHED is part of the
> batch process. Whether you change that instantly (i.e. publish articles
> as soon as they are ack'd) or every two weeks is then a minor change
> and a political rather than a technical issue.

That sounds good.  Pretty much what I am thinking.

I will start pulling some more detailed ideas together now for a post...