You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/05/16 14:00:31 UTC
[] Dynamic system with WWH (what we have)
[WARNING: Nicola Ken thinking out loud]
It seems that when we talk about a dynamic system, we talk about online
databases and servlets.
Is this *really* necessary?
Apache gives us these passive resources:
- CVS
- Bugzilla-Scarab
Ant these active resource:
- viewcvs
- Gump
The browser gives us these active resources:
- applets
- javascript
- forms
As you see, we have already more that a static website, and the last posts
to Forrest and Cocoon have brought to these conclusions.
Now, Forrest is a Community Tool, what others call a project/content
management system.
We need to
- do the sites of the projects
- do nagging-alerts
- make stats.
- recieve content updates
The first three can be done ala Gump, what remains is the CMS we need, and
what we have is CVS.
To view content with CVS in real-time we could use viewcvs.
Another option is to use an applet-Java app to get stuff from CVS and edit
it.
I think that this is the best solution, because it takes load from the
server and can be made to run *now*.
What do you think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [] Dynamic system with WWH (what we have)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Ivelin Ivanov" <iv...@apache.org>
> I can only comment on the applet option.
> If possible I would suggest that applets are avoided at this point.
> Unfortunately they're not quite predictable on windows platform,
especially
> with all the mess MS intentionally creates. I can't run applets on my
> Win98/IE 5.5 browser for a few months now.
Ok, applets are not well supported, I concede.
But we all have java, don't we ;-)
So I would prefer a JNPL launced Java Gui program.
> However I would opt for pushing xml/xslt to the client, so that the real
> time consuming operations are not performed on the server. By the time
> forrest is ready for prime time, majority of browser installations will
> support xslt.
Since we will publis static sites at first, it's not an option, but in the
future it's sure going to be important.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [] Dynamic system with WWH (what we have)
Posted by Ivelin Ivanov <iv...@apache.org>.
I can only comment on the applet option.
If possible I would suggest that applets are avoided at this point.
Unfortunately they're not quite predictable on windows platform, especially
with all the mess MS intentionally creates. I can't run applets on my
Win98/IE 5.5 browser for a few months now.
However I would opt for pushing xml/xslt to the client, so that the real
time consuming operations are not performed on the server. By the time
forrest is ready for prime time, majority of browser installations will
support xslt.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Thursday, May 16, 2002 7:00 AM
Subject: [] Dynamic system with WWH (what we have)
> [WARNING: Nicola Ken thinking out loud]
>
> It seems that when we talk about a dynamic system, we talk about online
> databases and servlets.
>
> Is this *really* necessary?
>
> Apache gives us these passive resources:
>
> - CVS
> - Bugzilla-Scarab
>
> Ant these active resource:
>
> - viewcvs
> - Gump
>
> The browser gives us these active resources:
>
> - applets
> - javascript
> - forms
>
> As you see, we have already more that a static website, and the last posts
> to Forrest and Cocoon have brought to these conclusions.
>
> Now, Forrest is a Community Tool, what others call a project/content
> management system.
>
> We need to
> - do the sites of the projects
> - do nagging-alerts
> - make stats.
> - recieve content updates
>
> The first three can be done ala Gump, what remains is the CMS we need, and
> what we have is CVS.
>
> To view content with CVS in real-time we could use viewcvs.
>
> Another option is to use an applet-Java app to get stuff from CVS and edit
> it.
>
> I think that this is the best solution, because it takes load from the
> server and can be made to run *now*.
>
> What do you think?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
RE: [] Dynamic system with WWH (what we have)
Posted by Steven Noels <st...@outerthought.org>.
Just an idea:
My favourite textwriting oriented XML editor (XMetal3) has a 'track
changes' feature (just as the revisions facility in Word), which uses
processing instructions to highlight changes in the XML-document.
original document:
<?xml version="1.0" encoding="UTF-8"?>
<slide>
<title>What is Cocoon</title>
<list>
<li>XML-based web publishing framework</li>
<li>XSLT all-the-way</li>
<li>Based on the SoC principle</li>
<li>Java Servlet based, but can be run from the commandline,
too</li>
<list>
<li>Pre-compilation</li>
<li>Generation of static site image</li>
</list>
<li>Based on Avalon, the Jakarta <em>server application
framework</em> (<link
href="http://jakarta.apache.org/avalon/">http://jakarta.apache.org/avalo
n/</link>)</li>
</list>
</slide>
after some modifications:
<?xml version="1.0" encoding="UTF-8"?>
<slide>
<title>What is Cocoon</title>
<list>
<li>
<?xm-insertion_mark_start author="Steven Noels"
time="20020516T212442+0100"?>here, I added an item to the
list<?xm-insertion_mark_end?>
</li>
<?xm-deletion_mark author="Steven Noels" time="20020516T212455+0100"
data="<li>XML-based web publishing framework</li>"?>
<li>XSLT all-the-way</li>
<li>Based on the SoC principle</li>
<li>Java Servlet based, but can be run from the commandline,
too</li>
<list>
<li>Pre-compilation</li>
<li>Generation of static site image</li>
</list>
<li>Based on Avalon, the Jakarta <em>server application
framework</em> (<link
href="http://jakarta.apache.org/avalon/">http://jakarta.apache.org/avalo
n/</link>)</li>
</list>
</slide>
I know in the CALS DTD, there exists markup elements for this too. But
it's long time ago I've been playing with that.
> We still have to think about the additional demands such a
> "distributed
> CMS" would place on the commit process. As with previous
> discussions on
> cocoon-dev, some are advocating that we patch first and deal with
> effects second. If any community member is allowed to patch
> any document
> in cvs, it would require that some committer subjectively review the
> patch before it can be committed. That may take a lot of time, if
> committer resources are low. For example, let's say you received ten
> QA-type patches from ten different community members for the *same*
> page. I don't even want to think how a cvs would merge diffs from so
> many docs. For documentation, it seems that evaluating diffs are a
> judgment call.
My personal subjective preference is towards distributing the
responsability of ack'ing patches. Nicola already knows my fear of
someone getting hit by a bus, the documentation follow-up shouldn't be
centralized neither.
> It also gets complicated when QA impacts multiple
> pages/internal links,
> etc.
>
> However, if we could model community QA content (for existing
> docs) as a
> separate document -- revision -- we could safely and quickly
> aggregate
> timely feedback into with existing doc content (showing up as
> comments
> at the end of the article, e.g.), Each QA patch is just a new
> revision
> doc with hooks to the existing problematic doc/page. Right
> now, I have a
> revisions/revision structure in my howto.dtd. However, we could pull
> revisions out and allow revision docs to stand on their own.
> That way,
> revisions could be applied without hesitation, and, from time
> to time,
> "merged" into existing doc content when a committer/editor
> has the time.
Yep, we should provide some lightweight XML markup for indicating
revisions, preferably in-place instead of grouped at the end of a
document.
I'll check if I find back how this was done in CALS.
</Steven>
Re: [] Dynamic system with WWH (what we have)
Posted by Diana Shannon <te...@mac.com>.
On Thursday, May 16, 2002, Nicola Ken Barozzi wrote:
> I think that this is the best solution, because it takes load from the
> server and can be made to run *now*.
>
> What do you think?
Lots of interesting ideas, Ken.
If you are referring to docs already in cvs (accessed via ViewCVS), then
we're probably talking about QA concerns, correct?
We still have to think about the additional demands such a "distributed
CMS" would place on the commit process. As with previous discussions on
cocoon-dev, some are advocating that we patch first and deal with
effects second. If any community member is allowed to patch any document
in cvs, it would require that some committer subjectively review the
patch before it can be committed. That may take a lot of time, if
committer resources are low. For example, let's say you received ten
QA-type patches from ten different community members for the *same*
page. I don't even want to think how a cvs would merge diffs from so
many docs. For documentation, it seems that evaluating diffs are a
judgment call.
It also gets complicated when QA impacts multiple pages/internal links,
etc.
However, if we could model community QA content (for existing docs) as a
separate document -- revision -- we could safely and quickly aggregate
timely feedback into with existing doc content (showing up as comments
at the end of the article, e.g.), Each QA patch is just a new revision
doc with hooks to the existing problematic doc/page. Right now, I have a
revisions/revision structure in my howto.dtd. However, we could pull
revisions out and allow revision docs to stand on their own. That way,
revisions could be applied without hesitation, and, from time to time,
"merged" into existing doc content when a committer/editor has the time.
Diana