Menu
▾
▴
cscene-discuss
You can subscribe to this list here.
| 2000 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: ixx <ix...@vi...> - 2000-01-05 15:39:27
|
On Wed, Jan 05, 2000 at 09:11:07AM -0600, Maria Callas wrote: > We don't need a domain called hash_c or anything else. wtf for? > it's just an irc channel =) hehe. its all the domain name fever going on. no no my dog does not need a domain name, you right. :) |
|
From: <j....@t-...> - 2000-01-05 07:15:11
|
On Wed, 5 Jan 2000 00:58:40 -0600, ixx wrote: >this is all in CVS i suppose? will check it out. sounds very nice and >flexible. It is. BTW, on what platform (uname -a) does cscene run? >ixx grabs the ü and tries to remove the umlat... i want those over my x You only get ÿ and Y, no X version of that (in Latin1). |
|
From: ixx <ix...@cs...> - 2000-01-05 06:59:49
|
On Wed, Jan 05, 2000 at 07:42:12AM +0100, Juergen Hermann wrote: > On Tue, 4 Jan 2000 21:51:04 -0600, ixx wrote: > > >i do not know if authors will have cvs access. because who knows who will be > >an author right? i want anyone to be able to submit an article. > > For now, I think the way to go is to have articles submitted through > the old mailing list as before, and the editor who takes care of an > article then adds it to an author directory (creating the dir when > needed). > > Later, we could have some (CGI) magic, but that is later. OK. was thinking of some type of "work" area for authors. anyhow that is a "feature" (or different project) for later. > As for how XML and translating to HTML works, I added a sample TODO this is all in CVS i suppose? will check it out. sounds very nice and flexible. > >we need a spot for preview too. will that be straight from CVS or a export > >into HTML on a preview site? > > CVS allows preview for sure. Anything else can be arranged if needed. yes of course. was thinging of the preview of a new issue.. could be pulled from cvs on to preview web site. unless articles come out in a slashdot fashion (when they are ready there they are...). in which case they would only be previewed by the person (or people) OKing it before release. thats fine to i suppose. ixx grabs the ü and tries to remove the umlat... i want those over my x |
|
From: ixx <ix...@cs...> - 2000-01-05 06:51:28
|
i am actually asleep... so i may not reply again tonight :) On Wed, Jan 05, 2000 at 01:46:21AM -0500, Paul W Brannan wrote: > > For now, I think the way to go is to have articles submitted through > > the old mailing list as before, and the editor who takes care of an > > article then adds it to an author directory (creating the dir when > > needed). > > It would be nice to do this in stages, so would could start taking article > submissions sooner rather than later. if this keeps moving like it is right now, then we could have *something* up for a "teaser" release in a week or so. > Also, how about RDF support so we can get a slashbox? I don't know much > about this, but I think it's a neat idea. it would be simple to do. of course we need more articles first :) |
|
From: Paul W B. <pb...@CL...> - 2000-01-05 06:47:55
|
> For now, I think the way to go is to have articles submitted through > the old mailing list as before, and the editor who takes care of an > article then adds it to an author directory (creating the dir when > needed). It would be nice to do this in stages, so would could start taking article submissions sooner rather than later. Also, how about RDF support so we can get a slashbox? I don't know much about this, but I think it's a neat idea. Paul (cout) |
|
From: <j....@t-...> - 2000-01-05 06:43:46
|
On Tue, 4 Jan 2000 21:51:04 -0600, ixx wrote:
>i do not know if authors will have cvs access. because who knows who will be
>an author right? i want anyone to be able to submit an article.
For now, I think the way to go is to have articles submitted through
the old mailing list as before, and the editor who takes care of an
article then adds it to an author directory (creating the dir when
needed).
Later, we could have some (CGI) magic, but that is later.
As for how XML and translating to HTML works, I added a sample TODO
list (and its HTML version). It's in the "admin" module, there you'll
find this:
admin/html/TODO.html TODO.xml
converted to XHTML
admin/xml/dtd/todo.dtd DTD for TODO list
admin/xml/TODO.xml TODO
list in XML form
admin/xml/xsl/todo.xhtml.xsl XML stylesheet
Note that the layout of the "TODO.html" file is nowhere defined in
TODO.xml, but in the stylesheet. You can have several stylesheet
working on the same XML source, i.e. you can have a textual version
("TODO.txt") too. You can also change the layout without
touching/changing the data in "TODO.xml".
In the same way, you can have an "articles.xml" from which you can
generate an index page, an author index, etc. pp.
>we need a spot for preview too. will that be straight from CVS or a export
>into HTML on a preview site?
CVS allows preview for sure. Anything else can be arranged if needed.
>OK. but i do not think we should require XML from authors.
HTML (when well-formed) _is_ XML. I agree we should not necessarily
require strict XML from authors. Not a thing we need to decide for now,
I think.
Ciao, Jürgen
|
|
From: ixx <ix...@cs...> - 2000-01-05 04:17:36
|
On Tue, Jan 04, 2000 at 07:59:20PM -0800, Steve Mertz wrote: > > This is just a test. I usually have a hard time getting on mailing lists > so just ignore this. you have been ignored. oops. |
|
From: Steve M. <sm...@pr...> - 2000-01-05 04:07:40
|
This is just a test. I usually have a hard time getting on mailing lists so just ignore this. -- Steve/Setz |
|
From: ixx <ix...@cs...> - 2000-01-05 03:52:12
|
On Wed, Jan 05, 2000 at 04:21:42AM +0100, Juergen Hermann wrote: > On Tue, 4 Jan 2000 19:52:17 -0600, ixx wrote: > >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. > > One possible way is this: add the article somewhere in the article tree > (the organization of which is to be discussed), then add a new line to > the article database (let's assume this is a text or XML file, so > that's easily done with CVS). A state change (REVIEW -> ACK) is then > also done via CVS. > > On the article tree: I think .../articles/<author>/foo.html (foo.xml) > would be the way to go, so each author can maintain his own stuff. Or > if only editors get CVS access, articles/<editor>/... > > If each author/editor has his own area, naming issues become obsolete, > the repository is organized, and each author can create subtrees (for > code archives or whatever). i do not know if authors will have cvs access. because who knows who will be an author right? i want anyone to be able to submit an article. maybe i will setup something for authors to work out of. anyhow i imagine only editors and web admin ppl will have cvs access. we need a spot for preview too. will that be straight from CVS or a export into HTML on a preview site? > >I have not played with xml much, but i be glad to provide perl coding, and > >learn xml on the way :) > > I have Cocoon running locally on a Win/NT and Apache basis, it's > extremely nice. Much of XML technology is Java, but C++ and Perl can be > used also, _especially_ for batch processing. Take a look at > xml.apache.org, it's a dynamic XML site based on Cocoon. OK. but i do not think we should require XML from authors. |
|
From: <j....@t-...> - 2000-01-05 03:23:16
|
On Tue, 4 Jan 2000 19:52:17 -0600, ixx wrote: >This is what I was wanting. Just not for mirrors. The backend and/or main >site. Then have the ability for static mirroring. Whatever technology you use, you can always "wget -r localhost" and create a static image. >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. One possible way is this: add the article somewhere in the article tree (the organization of which is to be discussed), then add a new line to the article database (let's assume this is a text or XML file, so that's easily done with CVS). A state change (REVIEW -> ACK) is then also done via CVS. On the article tree: I think .../articles/<author>/foo.html (foo.xml) would be the way to go, so each author can maintain his own stuff. Or if only editors get CVS access, articles/<editor>/... If each author/editor has his own area, naming issues become obsolete, the repository is organized, and each author can create subtrees (for code archives or whatever). >I have not played with xml much, but i be glad to provide perl coding, and >learn xml on the way :) I have Cocoon running locally on a Win/NT and Apache basis, it's extremely nice. Much of XML technology is Java, but C++ and Perl can be used also, _especially_ for batch processing. Take a look at xml.apache.org, it's a dynamic XML site based on Cocoon. >probably the easiest would be to search via the main cscene site and rewrite >the urls appropriately. Sure. That should be the default, and power-mirrors can add a local search. Ciao, Jürgen |
|
From: ixx <ix...@cs...> - 2000-01-05 01:53:22
|
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... |
|
From: <j....@t-...> - 2000-01-05 01:33:02
|
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. >Then we have the public layout. We have the front page and where it gets us. >Searching is often asked for feature. What about mirrors? 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). 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. 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. >What features can we add and still have the current mirrors? See 1. above. > what about searching with mirrors... Either they point to cscene or install the necessary stuff. Like you yourself already outlined... >3. mailing lists. > >will all be via source forge i imagine. maybe a new issue list should be setup? >my only other issue is what about lists using the cscene domain? i can host >them no problem. I think the cscene READER lists should be on cscene, the PROJECT lists on sourceforge. >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. Ciao, Jürgen |
|
From: <j....@t-...> - 2000-01-05 01:15:13
|
On Tue, 4 Jan 2000 18:59:57 -0600, ix...@cs... wrote: >you know this is nice and all...... but why don't i setup a *@cscene.org list? Well, I think it's better when the PROJECT related stuff is all under one hood. Ciao, Jürgen |
|
From: <ix...@cs...> - 2000-01-05 01:15:13
|
On Wed, Jan 05, 2000 at 02:10:47AM +0100, Juergen Hermann wrote: > On Tue, 4 Jan 2000 18:59:57 -0600, ix...@cs... wrote: > > >you know this is nice and all...... but why don't i setup a *@cscene.org > >list? > > Well, I think it's better when the PROJECT related stuff is all under one > hood. hmmmmmm i could setup lists.cscene.org to point to here but i do not know if it would matter. depends on their mail server. |
|
From: <ix...@cs...> - 2000-01-05 01:12:03
|
OK. Lets start discussing the look at feel of the new cscene. There are really two parts to this. The "staff" look, and the public look. The staff look is what we will see for doing updates to the site, for editing articles, for moderating articles, etc etc... that kind of jazz. Well you can 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. Then we have the public layout. We have the front page and where it gets us. Searching is often asked for feature. What about mirrors? What features can we add and still have the current mirrors? what about searching with mirrors... a few ideas for startes: 1. searching. all searching goes through the main site which checks the from addy and can rewrite all links to point to the mirror. or it could be required on all mirrors... or it is on main site and links are relative. 2. site management. most side management is via sourceforge CVS. editor management (moderation etc) is via some thing else.. they do not need to mess with the site.. just the new articles. maybe they say hey this is edited... then pass it along to a moderator area... there some people ok it then pass it on to CVS where it is added and then is sucked into main site (via CVS) every so often... 20 mins or what ever. or maybe the editors should access CVS directly? other ideas? 3. mailing lists. will all be via source forge i imagine. maybe a new issue list should be setup? my only other issue is what about lists using the cscene domain? i can host them no problem. 4. new issues. how should issues be released? instant from CVS? every 24 hours? every 2 weeks? reviewed before release from CVS (the articles would be reviewed on sumission i would think, but maybe the new issue needs a review). i like the idea of new things showing up real quick... but how quick? ok thats enough for now... btw if you want to get involved send me an email at ix...@cs... and tell me what you want to do. or for general ideas etc just post here. -ixx |
|
From: <ix...@cs...> - 2000-01-05 01:01:02
|
you know this is nice and all...... but why don't i setup a *@cscene.org list? |
