You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/01/22 14:52:57 UTC
Promotions, Revisioning and Workflow
Ok, now that I know what Robert meant with 'promotions' I want to give
you my impressions.
1) I've been talking about this 'CVS for XML' on the Xindice-dev mail
list. Check the mail archives
http://marc.theaimsgroup.com/?l=xindice-dev&r=1&w=2
2) I believe that a KMS *must* have the ability to do version control
and workflow management. Integrated. The two together, give you
'promotions'.
3) CVS is not enough.
4) Subversion is *much* better (http://subversion.tigris.org) but still
is 'file' based, an XML-based KMS needs 'node-granular' versioning
metadata
My dream KMS architecture is something like this:
[frontend] - [CMS] - [backend]
|
[store]
where cocoon powers both 'frontend' and 'backend', CMS wraps around an
native XML database and provides versioning, access control, transparent
query filtering and all the required things. 'store' is implemented with
a mix of 'native XML databases' and 'relational databases' (depending on
the needs, still I haven't designed the whole concept, but I'm not sure
that a native XML DB is capable of doing everything without serious
performance degradation).
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Punky Tse <pu...@yahoo.com>.
>
> I picture a web-based frontend as well as a web-based backend.
>
> Cocoon powers the backend just like it powers the frondend: serving the
> pages.
>
> Sure, you might not need the 'full' cocoon potentials on the back end
> (but to provide previews or completely WYSIWYG inline-editing, you do!)
> but I see the backend as an-editing oriented web(dav?) application on
> top of Cocoon.
>
> (yes, it's piece of cacke to add WebDAV functionality to Cocoon
> directly, it's just a bunch of new HTTP actions and some XML content,
> not a big deal for our machinery)
And, the backend can be written as cocoon-based app, mozilla-based app, java
app, Cocoa app or even Win32 MFC app!
I see that the backend is mainly used by content producers: they are
producer, editor and designer. Each of them has a specific role. For
example, editor writes the whole or partial content, the designer provides
graphics and style for the presentation, and the producer merges the content
from various editors, reject some of them, prove-read and assign style for
the final presentation. Hence, the backend system must present such logic
for this kind of workflow.
But which one provides workflow? Of course, it is the CMS. Hence, the
backend provides "frontend" to the content producers, while frontend
provides presentation to content consumers (viewers).
A clear picture now.
>
> Also, consider things like having editors down in Afganistan feeding
> their news via Palm connected to satellite cell-phones (UTMS anyone?),
> having their directors approuve the news while they are on an airplane,
> with the ability to annotate things directly on the page and without
> requiring any specific software to be installed on either client.
>
> See the need for cocoon on the backend? :)
I see, not only cocoon, but more!!
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
- Punky
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
>
> On Thursday 24 January 2002 13:55, Stefano Mazzocchi wrote:
> > . . .
> > (yes, it's piece of cacke to add WebDAV functionality to Cocoon
> > directly, it's just a bunch of new HTTP actions and some XML content,
> > not a big deal for our machinery)
>
> Wow - do you mean WebDAV retrieval AND storage?
Of course. WebDAV without storage is HTTP and we already support that
(in case you didn't know :)
> I assume versioning would be much harder, though?
It would not be handled by Cocoon, but by the underlying CMS (via some
strong contract, possibly a java API)
Another option is to have Subversion taking care of this (on the side of
Cocoon, so webdav PUT/updates are just redirected), but I don't think
subversion is powerful enough for what I have in mind (node-granular
versioning and access control, fast xpath/xquery, etc..)
and given the amount of time it takes, I think the best solution is a
java engine (read: Xindice)... but that's just my opinion.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Michael Hartle <mh...@hartle-klug.com>.
Bertrand Delacretaz wrote:
>On Thursday 24 January 2002 13:55, Stefano Mazzocchi wrote:
>
>>. . .
>>(yes, it's piece of cacke to add WebDAV functionality to Cocoon
>>directly, it's just a bunch of new HTTP actions and some XML content,
>>not a big deal for our machinery)
>>
I am highly interested in the complete design of such an extension; I am
still looking forward to use Cocoon/WebDAV as a basis for personalized
virtual harddisks, eg. as personal work environments, allowing every
user to personalize their view on the content structure. Yet trying to
extend Cocoon to be a solid designed basis for a virtual WebDAV storage
which contains dynamically-generated contents gave me some major headaches.
Issues I came across were things like the requirement of browsability of
directories (called collections in WebDAV), adequate ways to allow for
generation and filtering of directory "browse-lists" or proper
integration into the sitemap without allowing "ooops-its-no-more-WebDAV"
misconfigurations; it was then when I started drooling for the sitemap
componentization and being able to mount sub-"sitemaps" based on other
languages/concepts/etc.
>Wow - do you mean WebDAV retrieval AND storage?
>I assume versioning would be much harder, though?
>
Basically, when you have managed to provide WebDAV services via Cocoon
in a clean manner, then versioning is not that hard anymore; you'd still
have to think about versioning-capable storage backends.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Michael Hartle <mh...@hartle-klug.com>.
Matt Sergeant wrote:
>On Thu, 24 Jan 2002, Bertrand Delacretaz wrote:
>
>>Wow - do you mean WebDAV retrieval AND storage?
>>I assume versioning would be much harder, though?
>>
>WebDAV doesn't do versioning. "There is no V, only the appearance of a V".
>
There are WebDAV-related extensions that try to tackle versioning, like
DeltaV or the like.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Rendering a jsp : JSP it compiled 3 times -> performance problem
Posted by Kai Ulrich <ul...@pnpconsult.com>.
If I want to render a JSP (Struts Tags) with cocoon !
Everything works fine !
1. A servlet arrange the data an puts the beans to the request.
2. forward to the coocoon Servlet
...
RequestDispatcher rd =
etServletContext().getRequestDispatcher( "/cocoon/printBasket" );
rd.forward( req, res );
...
[web.xml]
...
<!-- Cocoon Servlet Mapping -->
<servlet-mapping>
<servlet-name>Cocoon2</servlet-name>
<url-pattern>/cocoon/*</url-pattern>
</servlet-mapping>
...
3. piped to the print.jsp
[sitemap.xmap]
...
<map:match pattern="cocoon/printBasket">
<map:generate type="jsp" src="print/printBasket.jsp"/>
<map:transform src="stylesheets/print2fo.xsl"/>
<map:serialize type="fo2pdf"/>
</map:match>
...
But I have a little performance Pronblem:
- One thing attracted attention : By the executing the pipe, the JSP it
compiled 3 times and the servlet is executed 2 more times!
Is that usual ? Can I do thome thing to get a better performance ?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 24 Jan 2002, Bertrand Delacretaz wrote:
> On Thursday 24 January 2002 13:55, Stefano Mazzocchi wrote:
> > . . .
> > (yes, it's piece of cacke to add WebDAV functionality to Cocoon
> > directly, it's just a bunch of new HTTP actions and some XML content,
> > not a big deal for our machinery)
>
> Wow - do you mean WebDAV retrieval AND storage?
> I assume versioning would be much harder, though?
WebDAV doesn't do versioning. "There is no V, only the appearance of a V".
:-)
--
<!-- Matt -->
<:->Get a smart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 24 January 2002 13:55, Stefano Mazzocchi wrote:
> . . .
> (yes, it's piece of cacke to add WebDAV functionality to Cocoon
> directly, it's just a bunch of new HTTP actions and some XML content,
> not a big deal for our machinery)
Wow - do you mean WebDAV retrieval AND storage?
I assume versioning would be much harder, though?
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Per-Olof Norén <pe...@alma.nu>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, January 24, 2002 1:55 PM
Subject: Re: Promotions, Revisioning and Workflow
> Punky Tse wrote:
> >
> > > My dream KMS architecture is something like this:
> > >
> > > [frontend] - [CMS] - [backend]
> > > |
> > > [store]
> > >
> > > where cocoon powers both 'frontend' and 'backend', CMS wraps around an
> > > native XML database and provides versioning, access control,
transparent
> > > query filtering and all the required things. 'store' is implemented
with
> > > a mix of 'native XML databases' and 'relational databases' (depending
on
> > > the needs, still I haven't designed the whole concept, but I'm not
sure
> > > that a native XML DB is capable of doing everything without serious
> > > performance degradation).
What about slide? It has most of the above features.
/Per-Olof
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Punky Tse wrote:
>
> > My dream KMS architecture is something like this:
> >
> > [frontend] - [CMS] - [backend]
> > |
> > [store]
> >
> > where cocoon powers both 'frontend' and 'backend', CMS wraps around an
> > native XML database and provides versioning, access control, transparent
> > query filtering and all the required things. 'store' is implemented with
> > a mix of 'native XML databases' and 'relational databases' (depending on
> > the needs, still I haven't designed the whole concept, but I'm not sure
> > that a native XML DB is capable of doing everything without serious
> > performance degradation).
> >
> > What do you think?
>
> So what is the role of Cocoon at backend? Is it used to handle all sort of
> generation and transformation? Obviously, frontend is used for
> presentation.
I picture a web-based frontend as well as a web-based backend.
Cocoon powers the backend just like it powers the frondend: serving the
pages.
Sure, you might not need the 'full' cocoon potentials on the back end
(but to provide previews or completely WYSIWYG inline-editing, you do!)
but I see the backend as an-editing oriented web(dav?) application on
top of Cocoon.
(yes, it's piece of cacke to add WebDAV functionality to Cocoon
directly, it's just a bunch of new HTTP actions and some XML content,
not a big deal for our machinery)
Also, consider things like having editors down in Afganistan feeding
their news via Palm connected to satellite cell-phones (UTMS anyone?),
having their directors approuve the news while they are on an airplane,
with the ability to annotate things directly on the page and without
requiring any specific software to be installed on either client.
See the need for cocoon on the backend? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Punky Tse <pu...@yahoo.com>.
> My dream KMS architecture is something like this:
>
> [frontend] - [CMS] - [backend]
> |
> [store]
>
> where cocoon powers both 'frontend' and 'backend', CMS wraps around an
> native XML database and provides versioning, access control, transparent
> query filtering and all the required things. 'store' is implemented with
> a mix of 'native XML databases' and 'relational databases' (depending on
> the needs, still I haven't designed the whole concept, but I'm not sure
> that a native XML DB is capable of doing everything without serious
> performance degradation).
>
> What do you think?
So what is the role of Cocoon at backend? Is it used to handle all sort of
generation and transformation? Obviously, frontend is used for
presentation.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
Punky
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow (yahoogroups, CMS use-cases)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 24 January 2002 14:10, Stefano Mazzocchi wrote:
> . .
> > (http://groups.yahoo.com/group/contentmanagementgroup/).
>
> Ok, subscribed there. (god, yet another mail list :(
Note that I just posted to general@xml.apache.org about the possibility of
creating a "CMS requirements" project under the Apache umbrella.
There seems to be quite a lot of interest about getting a CMS project going,
and agreement about the need to write requirements first (well, isn't that a
good idea ;-)
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow (yahoogroups, CMS use-cases)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
>
> Note that we're starting to have an interesting discussion about CMS
> requirements over at yahoogroups
> (http://groups.yahoo.com/group/contentmanagementgroup/).
Ok, subscribed there. (god, yet another mail list :(
Matt, maybe we could move there the discussion we had in mind about
abstracting the 'publishing framework' (gosh, the Wyona guys call it
'pipeline systems', we need to tight those bolts :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow (yahoogroups, CMS use-cases)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Note that we're starting to have an interesting discussion about CMS
requirements over at yahoogroups
(http://groups.yahoo.com/group/contentmanagementgroup/).
Hopefully we'll be able to come up with a set of use cases and requirements
for a CMS.
- Bertrand
On Wednesday 23 January 2002 11:56, Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
> > On Tuesday 22 January 2002 14:52, Stefano Mazzocchi wrote:
> > >. . .
> > > 3) CVS is not enough.
> >
> > In the long run or for "big" projects I agree, but unless there
> > is an alternative today that is easy to install and as solid as CVS (I
> > don't know much about subversion though), I think CVS could do for many
> > small to medium-sized projects.
>
> Granted and agreed.
>
> > CvsGeneratorUsingCvsTagsToRetrieveVersions, anyone?
> > (I hate looking dumb - but maybe someone is going to say "it's
> > already in Cocoon", so why not give it a try ;-)
>
> Hey, what about ripping out the NetBeans CVS Protocol library (which is
> legally compatible with us, unlike the JCVS library) and use that to
> write a generator?
>
> Any volunteer?
>
> > > . .
> > > My dream KMS architecture is something like this:
> > >
> > >
> > > [frontend] - [CMS] - [backend]
> > >
> > > [store]
> >
> > Yes!
> >
> > IMHO the need right now is in defining the interfaces between these
> > components. A tall order for sure...
>
> Yes, this needs to happen sometimes.... but I don't want to put too many
> irons in the fire just yet (Cocoon and Forrest will suck all my free
> time now) but I keep an eye on XIndice to make it possible in the future
> to use it as part of that [store] component.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Michael Hartle wrote:
>
>>I tried it, but IIRC, I got caching problems, thus I wrote the
>>UnzipGenerator.
>>
>
>Care to share? :)
>
Definitely ;) My workload should soon return to more normal levels,
giving me the opportunity to put it in a nice donation package with a
not-polished-but-functional Documentum DocbaseSource plus some developer
& user-documentation.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Stefano Mazzocchi wrote:
>
> >Michael Hartle wrote:
> >
> >>Stefano Mazzocchi wrote:
> >>
> >>>Hey, what about ripping out the NetBeans CVS Protocol library (which is
> >>>legally compatible with us, unlike the JCVS library) and use that to
> >>>write a generator?
> >>>
> >>Just a thought, why not rather turn it into a cvs protocol ? It would
> >>then allow everyone to choose generators as they wish; I recently hacked
> >>an UnzipGenerator and enjoyed combining it with another protocol ;)
> >>
> >
> >Agreed, a cvs: protocol handler would be even better.
> >
> >anyway, why an UnzipGenerator? doesn't the jar: protocol already does
> >that?
> >
> I tried it, but IIRC, I got caching problems, thus I wrote the
> UnzipGenerator.
Care to share? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Michael Hartle wrote:
>
>>Stefano Mazzocchi wrote:
>>
>>>Hey, what about ripping out the NetBeans CVS Protocol library (which is
>>>legally compatible with us, unlike the JCVS library) and use that to
>>>write a generator?
>>>
>>Just a thought, why not rather turn it into a cvs protocol ? It would
>>then allow everyone to choose generators as they wish; I recently hacked
>>an UnzipGenerator and enjoyed combining it with another protocol ;)
>>
>
>Agreed, a cvs: protocol handler would be even better.
>
>anyway, why an UnzipGenerator? doesn't the jar: protocol already does
>that?
>
I tried it, but IIRC, I got caching problems, thus I wrote the
UnzipGenerator.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Stefano Mazzocchi wrote:
>
> >Hey, what about ripping out the NetBeans CVS Protocol library (which is
> >legally compatible with us, unlike the JCVS library) and use that to
> >write a generator?
> >
> Just a thought, why not rather turn it into a cvs protocol ? It would
> then allow everyone to choose generators as they wish; I recently hacked
> an UnzipGenerator and enjoyed combining it with another protocol ;)
Agreed, a cvs: protocol handler would be even better.
anyway, why an UnzipGenerator? doesn't the jar: protocol already does
that?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> > I recently hacked
> > an UnzipGenerator and enjoyed combining it with another protocol ;)
>
> Hm... How about ZipSerializer? ;)
Careful: if you want to provide 'compressed' version of out output, then
I think that servlet filtering is the way to go (tomcat comes with a
GzipFilter, doesn't it?)
on the other hand, if you want to provide import/export of OpenOffice
files (or any zipped archive) I'd suggest to create a specific
serializer and not a generic ZipSerializer which might be seriouly
misleading in the filtering direction.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Promotions, Revisioning and Workflow
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Michael Hartle [mailto:mhartle@hartle-klug.com]
>
> Stefano Mazzocchi wrote:
>
> >Hey, what about ripping out the NetBeans CVS Protocol library (which
is
> >legally compatible with us, unlike the JCVS library) and use that to
> >write a generator?
> >
> Just a thought, why not rather turn it into a cvs protocol ? It would
> then allow everyone to choose generators as they wish;
I agree with you completely.
> I recently hacked
> an UnzipGenerator and enjoyed combining it with another protocol ;)
Hm... How about ZipSerializer? ;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Hey, what about ripping out the NetBeans CVS Protocol library (which is
>legally compatible with us, unlike the JCVS library) and use that to
>write a generator?
>
Just a thought, why not rather turn it into a cvs protocol ? It would
then allow everyone to choose generators as they wish; I recently hacked
an UnzipGenerator and enjoyed combining it with another protocol ;)
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
>
> On Tuesday 22 January 2002 14:52, Stefano Mazzocchi wrote:
> >. . .
> > 3) CVS is not enough.
>
> In the long run or for "big" projects I agree, but unless there
> is an alternative today that is easy to install and as solid as CVS (I don't
> know much about subversion though), I think CVS could do for many small to
> medium-sized projects.
Granted and agreed.
> CvsGeneratorUsingCvsTagsToRetrieveVersions, anyone?
> (I hate looking dumb - but maybe someone is going to say "it's
> already in Cocoon", so why not give it a try ;-)
Hey, what about ripping out the NetBeans CVS Protocol library (which is
legally compatible with us, unlike the JCVS library) and use that to
write a generator?
Any volunteer?
> > . .
> > My dream KMS architecture is something like this:
> >
> >
> > [frontend] - [CMS] - [backend]
> > |
> > [store]
>
> Yes!
>
> IMHO the need right now is in defining the interfaces between these
> components. A tall order for sure...
Yes, this needs to happen sometimes.... but I don't want to put too many
irons in the fire just yet (Cocoon and Forrest will suck all my free
time now) but I keep an eye on XIndice to make it possible in the future
to use it as part of that [store] component.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
CVS, RE: Promotions, Revisioning and Workflow
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
>
>
> CvsGeneratorUsingCvsTagsToRetrieveVersions, anyone?
CVSSource sounds better... Check out jCVS - might be of great help...
(http://www.trustice.com/java/jcvs/)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 22 January 2002 14:52, Stefano Mazzocchi wrote:
>. . .
> 3) CVS is not enough.
In the long run or for "big" projects I agree, but unless there
is an alternative today that is easy to install and as solid as CVS (I don't
know much about subversion though), I think CVS could do for many small to
medium-sized projects.
CvsGeneratorUsingCvsTagsToRetrieveVersions, anyone?
(I hate looking dumb - but maybe someone is going to say "it's
already in Cocoon", so why not give it a try ;-)
> . .
> My dream KMS architecture is something like this:
>
>
> [frontend] - [CMS] - [backend]
> |
> [store]
Yes!
IMHO the need right now is in defining the interfaces between these
components. A tall order for sure...
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 24 Jan 2002, Andrew Answer wrote:
> Hello Stefano,
>
> you know anything about Perl-written CVS-integrated collaboration
> system Twiki (http://twiki.org/) and his Java servlet-based analogue
> WebTrans (http://sourceforge.net/projects/webtrans/,
> http://www.devtools.org/servlet/wiki/FrontPage), written by Rus
> Heywood? May be this code can be integrated into C2...
> Importance of this system in new ideas area. You can see to the site from
> other point of view: as "collaboration system" instead of "publishing
> engine" - i think, two-sided streams of data is a future of
> web-world...
>
> Now i try programming something link between systems, but i have too
> little exp for fast work. Listen your comments...
A better place to start would be Bricolage at http://bricolage.sf.net/,
which is built on the experiences of the guys who built the Salon CMS.
It's Perl, but it's got some extremely solid ideas.
--
<!-- Matt -->
<:->Get a smart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Promotions, Revisioning and Workflow
Posted by Andrew Answer <A....@ftc.ru>.
Hello Stefano,
you know anything about Perl-written CVS-integrated collaboration
system Twiki (http://twiki.org/) and his Java servlet-based analogue
WebTrans (http://sourceforge.net/projects/webtrans/,
http://www.devtools.org/servlet/wiki/FrontPage), written by Rus
Heywood? May be this code can be integrated into C2...
Importance of this system in new ideas area. You can see to the site from
other point of view: as "collaboration system" instead of "publishing
engine" - i think, two-sided streams of data is a future of
web-world...
Now i try programming something link between systems, but i have too
little exp for fast work. Listen your comments...
>*************Original message*************
> From: Stefano Mazzocchi <st...@apache.org>
> To: Apache Cocoon <co...@xml.apache.org>
> Date: Tuesday, January 22, 2002, 7:52:57 PM
> Subject: Promotions, Revisioning and Workflow
> Ok, now that I know what Robert meant with 'promotions' I want to give
> you my impressions.
> 1) I've been talking about this 'CVS for XML' on the Xindice-dev mail
> list. Check the mail archives
> http://marc.theaimsgroup.com/?l=xindice-dev&r=1&w=2
> 2) I believe that a KMS *must* have the ability to do version control
> and workflow management. Integrated. The two together, give you
> 'promotions'.
> 3) CVS is not enough.
> 4) Subversion is *much* better (http://subversion.tigris.org) but still
> is 'file' based, an XML-based KMS needs 'node-granular' versioning
> metadata
> My dream KMS architecture is something like this:
> [frontend] - [CMS] - [backend]
> |
> [store]
> where cocoon powers both 'frontend' and 'backend', CMS wraps around an
> native XML database and provides versioning, access control, transparent
> query filtering and all the required things. 'store' is implemented with
> a mix of 'native XML databases' and 'relational databases' (depending on
> the needs, still I haven't designed the whole concept, but I'm not sure
> that a native XML DB is capable of doing everything without serious
> performance degradation).
> What do you think?
>*************Original message*************
Best regards,
Andrew Answer A.Nuzhdov@ftc.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org