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 2001/12/05 20:15:52 UTC
[Summary] Dreams, RTs and getting the stuff done
I've been having a private conversation from somebody on the list that
'suggested' that we should focus on something and getting it done rather
than dreaming on many things and dilute our effort.
This made me think about the impact of this RT-style open development on
community dynamics.
I strongly believe in open development and open design and I think RT
are some great way of working together without worries of saying
something that turns out a bad idea.
At the same time, I agree that I've been dropping on this list all the
random thoughs that I had during the last 12 months of absence from the
OSS world.
And considering the amount of thinking I normally do everytime I have
some free time (while driving, before going to sleep, walking from one
place to another, talking with geeky friends, etc.) a full year of RT
it's tough to digest without a global vision that explains my
intentions.
So, here I express my visions and my intentions to get them done in a
professional and focused way.
- o -
Stream of Thought #1: community dynamics
----------------------------------------
The Cocoon Community does both research and development. Its dyamics can
be visualized as follows:
+-> research ----> develop ---> produce ----> use --+
| |
+---------------------- report ----------------------+
The difficult thing is placing enough social inertia in the loop to
detach it to the single individuals that make up the community. When
this happens, the community can be said "healthy" and "stable".
Some people (read recent Linus Torvald's comments on the Linux Kernel
dev mail list) make a parallel between this system and a biological
ecosystem, arriving to call the process that creates open source
software as "evolutionary software darwinism".
The first person that I heard using this expression was James Davidson a
couple of years ago. I'm happy to see that Linus now adopts the same
concepts.
Anyway, unlike natural evolution witch is a globally stocastic process,
community dynamics act as "directed evolution", thus performing at a
faster rate.
In this context, I believe that RT-style research can be seen as an
evolutionary catalizer that improves the pace of cross-hybridization of
ideas, thus resulting in faster R&D times.
There is no way for me to prove this, but my very high success as a
community bootstrapper (no OSS project that I started failed to get
enough inertia to continue without me) leads me to think there must be
some truth in this.
At the same time, while a higher mutation frequency in biological
populations might increase diversity and provide faster evolutionary
cycles, a frequency too high might degenerate the population since there
is no time to adapt to the changes.
So, if RT work like mutations and cross-pollination for biological
system, we must be careful to avoid the saturation of resources and
leave time for changes to percolate thru the community and be solidified
into code so that the loop can continue.
Without a fast loop (that is: a fast release cycle!), the process looses
stability and degenerates vitality.
I believe the perfect match is one bugfix release per month (at least!)
and no more than two back incompatible releases per year (hopefully
none).
- o -
Stream of Thought #2: The perfect KMS
-------------------------------------
KMS stands for "knowledge management system". It's a marketing buzzword
that indicates systems (mostly targetted for intranet use) that are
capable of managing and making available 'corporate knowledge', the
company information, in such a way that it's easily created, easily
published and easily accessible.
A typical KMS is composed of:
1) a front-end
2) a back-end
3) a content-editing system
4) a search engine
5) an administration toolkit
the idea is to come up with solid and open software solutions that
implement all the above key pieces, then sell the service to glue them
together for customer needs.
The map between those pieces and existing software is *far* from being
accomplished but we are heading in the right direction. My guesses are
for software mapping are:
1) front-end -> Cocoon
2) back-end -> XIndice or a Cocoon-based CMS layer wrapping XIndice
3) editing system -> ??? (Mozilla based inline editor being my best
guess)
4) search-engine -> ??? (The lucene-based indexing appears a first step
in the right direction)
5) administration toolkit -> cocoon webapp
I will now explain my ideas on each component.
- o -
Stream of Thought #2.1: the front-end
-------------------------------------
Cocoon is a publishing system but many hit a wall by using it and they
understood the hard way that:
"there is no distinction between web publishing and web applications"
So, in order to remove this wall, we have to rethink the Cocoon
architecture in order to make it easier to create web applications with
Cocoon.
The problem has been idenfitied by many as a limitation in functionality
of the sitemap, that was designed for "outward" flow of information and
didn't take 'inward' flow into deep consideration.
One of the proposed solution is to enhance the sitemap semantics to
incorporate concepts from "finite state machines".
Another solution is the incorporation of the concepts of Scheme
'continuations'.
The debate is not over, nor any complete solution has been proposed that
makes everybody happy.
There is no release plan nor time frame for this, even if many believe
it's very important to make Cocoon stand user requirements.
Research on this topic will continue on this list.
- o -
Stream of Thought #2.2: The back-end
------------------------------------
I wanted the dbXML project (now XIndice) to move over to Apache because
I think it could be a wonderful seed to grow a community around this
"back-end" concept of a semi-structured content management system.
This CMS could be XIndice alone or XIndice as the storage core and a
wrapping layer that performs versioning/revisionsing and deals with
metadata.
Of course, the goal is to connect this back-end with the front-end, so
interoperability between Cocoon and XIndice (either direct or thru a CMS
layer)
Now that the Apache XIndice project is starting, I'll move over my
effort on the xindice-dev@xml.apache.org mail list and will continue the
R&D there.
- o -
Stream of Thought #2.3: The content-editing system
--------------------------------------------------
Following the SoC patterns, content should be edited and modified by
editors, people that have specific writing and authoring skills but
normally lack technical ones.
For this reason, the editing system should require the little possible
effort and integrate seemlessly with the editing environment the persons
are used to.
At the same time, the software should not give any more editing freedom
than what their concerns require. For this reason, a pure WYSIWYG
solution is considered harmful.
The proposed solution is a constrained-WYSIWYG editing system that
allows visual feedback to help the writer contextualize the edited
content, thus simplifying the editing approach, but limits the editing
capability to those areas where writer is allowed/capable of working on.
The required features are:
1) portability: it should work on any system
2) integration: it should integrate with existing systems
3) full WYSIWIG capacity: it should incorporate a full web rendering
system (HTML,CSS,javascript with native XML/XSLT/SVG/XForm capabilities
as a clear plus, but not necessary)
4) customizable: it should allow easy customization of editing needs
Several software technologies were analyzed but the most proposing seems
to be the Mozilla Project (www.mozilla.org) which is portable and
contains a very modular and highly customizable architecture, along with
the fact that it's an open source project, thus safe ground to invest a
technological effort upon.
On the other hand, given personal lack of time and C++ experience and
lack of sponsoring on this side, this effort put on hold, even if I'll
keep an eye on Mozilla to see if they implement the required
inline-editing components.
Anyway, if others want to push this forward, I'll be happy to join them.
- o -
Stream of Thought #2.4: The search-engine
-----------------------------------------
Unlike many believe, searching and indexing of the content of a KMS
cannot be performed from the backend level since this level doesn't
contain the URI->resource information (which is necessarely contained in
the front end).
For this reason, the indexer must necessary connect to the front of the
system (either simulating user requests, or directly hitting the
publishing engine avoiding the request/response
serialization/deserialization overhead).
Even the search part is clearly to be connected to the front end. For
these reasons, I believe the search engine effort should be performed
between the Cocoon and Lucene projects.
I have some ideas that I presented at some ETH (Zurich Institute of
Technology) folks that I will submit in the short future. Unfortunately,
they require some changes in Lucene, for this reason, I'll subscribe to
that list as well and continue the effort between here and there.
- o -
Stream of Thought #2.5: The administration toolkit
--------------------------------------------------
The administration toolkit should be a front-end application.
Another limitation that has been identified in Cocoon is the lack of
modularity at the application level.
I proposed a solution that follows the WAR concepts and uses the
abstraction that cocoon-specific URL protocols allow (as Mozilla does)
to make componentization possible even at the application level.
I will continue this research within Cocoon-dev because it's not only
useful for an administration toolkit but it's a very interesting concept
that would make it easier to create hot-deployable application-level
cocoon subprojects that encapsulate all necessary parts (along with
webapp-specific components, logicsheets, stylesheets, resources,
sitemaps and what not).
- o -
This is an ambitious plan and won't happen overnight. I'm fully aware of
this.
For the pessimists between you, I can only say that my dream, back in
early 1998, was to turn a single-project virtual host named
java.apache.org in a full backoffice suite for web services.
And the only project we had was Apache JServ version 0.9.11 alpha.
I expect the entire effort to take between 12 and 18 months to complete.
Faster if I find sponsoring or jobs that require this software as the
engine (as I'm currently trying to do).
(if you are capable of providing such sponsoring because you like my
plan and you think it's worth for your own company/effort, please let me
know privately).
I hope this gives you an idea of what my visions for the future of this
project are.
Hope this helps.
--
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: [Summary] Dreams, RTs and getting the stuff done
Posted by Stefano Mazzocchi <st...@apache.org>.
Carlos wrote:
> > Stream of Thought #2: The perfect KMS
> > -------------------------------------
> >
> > KMS stands for "knowledge management system". It's a marketing buzzword
> > that indicates systems (mostly targetted for intranet use) that are
> > capable of managing and making available 'corporate knowledge', the
> > company information, in such a way that it's easily created, easily
> > published and easily accessible.
> >
> > A typical KMS is composed of:
> >
> > 1) a front-end
> > 2) a back-end
> > 3) a content-editing system
> > 4) a search engine
> > 5) an administration toolkit
> >
> > the idea is to come up with solid and open software solutions that
> > implement all the above key pieces, then sell the service to glue them
> > together for customer needs.
>
> Another use for this system is a Course Management System. I would love to
> have an Open Source Solution that is already going where most of the major
> commercial CMS vendors are going.
Oh, well, the KMS is only the first of my big projects :)
The next is an e-learning framework based on that KMS, plus time-based
user reaction statistical analysis and based on the concepts of
cognitive dissonance. My girlfriend and I spent entire nights talking
about how such a system should work. We have some very nice ideas, but
they are still very much up in the air.
> >
> > The map between those pieces and existing software is *far* from being
> > accomplished but we are heading in the right direction. My guesses are
> > for software mapping are:
> >
> > 1) front-end -> Cocoon
> > 2) back-end -> XIndice or a Cocoon-based CMS layer wrapping XIndice
> > 3) editing system -> ??? (Mozilla based inline editor being my best
> > guess)
> > 4) search-engine -> ??? (The lucene-based indexing appears a first step
> > in the right direction)
> 4.1 a user/data management layer where we can record and archive information
> about the users' interaction with the system. Perhaps as simple as a
> database that gets created for each instance.
In my vision, the e-learning framework is just a specialized KMS with
some additional functionalities in the front-end (advanced user tracking
and statistlical analysis), and some more metadata in the back-end
(course-specific metadata and cognitive trails indicators). And a
specific administration part.
But it wouldn't require changes in the overall architecture.
> > Stream of Thought #2.3: The content-editing system
> > --------------------------------------------------
> >
> > Following the SoC patterns, content should be edited and modified by
> > editors, people that have specific writing and authoring skills but
> > normally lack technical ones.
> >
> > For this reason, the editing system should require the little possible
> > effort and integrate seemlessly with the editing environment the persons
> > are used to.
> >
> > At the same time, the software should not give any more editing freedom
> > than what their concerns require. For this reason, a pure WYSIWYG
> > solution is considered harmful.
> >
> > The proposed solution is a constrained-WYSIWYG editing system that
> > allows visual feedback to help the writer contextualize the edited
> > content, thus simplifying the editing approach, but limits the editing
> > capability to those areas where writer is allowed/capable of working on.
> You lost me here. You're presuming that whoever works with this editor
> already has a skill set of, at least, HTML, correct?
Absolutely not. The editor simply types text in some areas where he/she
is allowed to. Also, if allowed, it could 'enhance' the text by using
'bold' and 'italic' or creating hyperlinks that are later trasformed
into semantic markup (strong for bold, emphasis for italic, xlink for
hyperlinks and so on)
Only the HTML designer will have to work on HTML, but I'm not concerned
about those editing needs since they are normally exercized at
site-construction time while content editing will performed for years
(or even decades!) by web-untrained people (which are *much* less
expensive than content writers with HTML skills!)
> I would love to see the results and help as much as I can, although I'm a
> very beginner Java programmer, I've always loved Cocoon as a concept and as
> an application
Oh, don't worry, even watching over our shoulders and sending
suggestions/comments is a great way of collaborating. In fact, without
feedback, the community dynamics wouldn't be stable and would diverge on
developers dream, loosing contact with reality and destroying the
project as a result.
--
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: [Summary] Dreams, RTs and getting the stuff done
Posted by Carlos <ca...@cvc.edu>.
> From: Stefano Mazzocchi <st...@apache.org>
> Reply-To: cocoon-dev@xml.apache.org
> Date: Wed, 05 Dec 2001 20:15:52 +0100
> To: Apache Cocoon <co...@xml.apache.org>
> Subject: [Summary] Dreams, RTs and getting the stuff done
>
>
>
> Stream of Thought #2: The perfect KMS
> -------------------------------------
>
> KMS stands for "knowledge management system". It's a marketing buzzword
> that indicates systems (mostly targetted for intranet use) that are
> capable of managing and making available 'corporate knowledge', the
> company information, in such a way that it's easily created, easily
> published and easily accessible.
>
> A typical KMS is composed of:
>
> 1) a front-end
> 2) a back-end
> 3) a content-editing system
> 4) a search engine
> 5) an administration toolkit
>
> the idea is to come up with solid and open software solutions that
> implement all the above key pieces, then sell the service to glue them
> together for customer needs.
Another use for this system is a Course Management System. I would love to
have an Open Source Solution that is already going where most of the major
commercial CMS vendors are going.
>
> The map between those pieces and existing software is *far* from being
> accomplished but we are heading in the right direction. My guesses are
> for software mapping are:
>
> 1) front-end -> Cocoon
> 2) back-end -> XIndice or a Cocoon-based CMS layer wrapping XIndice
> 3) editing system -> ??? (Mozilla based inline editor being my best
> guess)
> 4) search-engine -> ??? (The lucene-based indexing appears a first step
> in the right direction)
4.1 a user/data management layer where we can record and archive information
about the users' interaction with the system. Perhaps as simple as a
database that gets created for each instance.
> 5) administration toolkit -> cocoon webapp
>
> I will now explain my ideas on each component.
>
> - o -
>
<section sniped>
> Stream of Thought #2.3: The content-editing system
> --------------------------------------------------
>
> Following the SoC patterns, content should be edited and modified by
> editors, people that have specific writing and authoring skills but
> normally lack technical ones.
>
> For this reason, the editing system should require the little possible
> effort and integrate seemlessly with the editing environment the persons
> are used to.
>
> At the same time, the software should not give any more editing freedom
> than what their concerns require. For this reason, a pure WYSIWYG
> solution is considered harmful.
>
> The proposed solution is a constrained-WYSIWYG editing system that
> allows visual feedback to help the writer contextualize the edited
> content, thus simplifying the editing approach, but limits the editing
> capability to those areas where writer is allowed/capable of working on.
You lost me here. You're presuming that whoever works with this editor
already has a skill set of, at least, HTML, correct?
I would love to see the results and help as much as I can, although I'm a
very beginner Java programmer, I've always loved Cocoon as a concept and as
an application
Carlos
--
Carlos E. Araya
---+ WebCT Administrator/Trainer
G | California Virtual Campus
- | C/O De Anza College
P | 21250 Stevens Creek Blvd
---+ Cupertino, CA 95014
email carlos@cvc.edu
web http://www.cvc1.org/ (work)
http://www.silverwolf-net.net (personal)
phone 408 257 0420 (work)
PGP Fingerprint E629 5DFD 7EAE 4995 E9D7 3D2F 5A9F 0CE7 DFE7 1756
Choose your friends by their character and your socks by their color.
Choosing your socks by their character makes no sense, and choosing your
friends by their color is unthinkable."
--anonymous
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Summary] Dreams, RTs and getting the stuff done
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
>
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: woensdag 5 december 2001 20:16
> > To: Apache Cocoon
> > Subject: [Summary] Dreams, RTs and getting the stuff done
> >
> >
> > I've been having a private conversation from somebody on the list that
> > 'suggested' that we should focus on something and getting it done rather
> > than dreaming on many things and dilute our effort.
>
> here's 'somebody' - perhaps we should mention that it started off with severe mutual
> misunderstandings & subsequent impoliteness ;-)
Which was later clarified with double-sided apologies :) but had the
result of straighten my attitude a little bit and provide context for
others to jump on my train. Which is a great thing.
> > Stream of Thought #2: The perfect KMS
> > -------------------------------------
> >
> > KMS stands for "knowledge management system". It's a marketing buzzword
> > that indicates systems (mostly targetted for intranet use) that are
> > capable of managing and making available 'corporate knowledge', the
> > company information, in such a way that it's easily created, easily
> > published and easily accessible.
> >
> > A typical KMS is composed of:
> >
> > 1) a front-end
> > 2) a back-end
> > 3) a content-editing system
> > 4) a search engine
> > 5) an administration toolkit
> >
> > the idea is to come up with solid and open software solutions that
> > implement all the above key pieces, then sell the service to glue them
> > together for customer needs.
> >
> > The map between those pieces and existing software is *far* from being
> > accomplished but we are heading in the right direction.
>
> To conclude our private conversation: a KMS should *at least* be able to facilitate &
> support the cycle you mention above:
>
> +-> research ----> develop ---> produce ----> use --+
> | |
> +---------------------- report ----------------------+
>
Oh, absolutely! I shouldn't remind you that Cocoon started *exactly* to
provide a front-end for our own documentation system on apache.org
projects! This KMS is much more than that, but it's indeed something I'd
scream to have to power our own site!
[Imagine editing our docs directly thru our browser and have them
translated in docbook automagically, then have a simple workflow system
that allows us to publish the content directly via web... oh, dear, I
want it soooo bad! :-]
> and as such is likely to have some overlaps with the d-haven.org/docoport dream
> mentioned earlier on this list.
Hmmm, I don't think Berin can overlap with something going on here. I'd
say the opposite: docoport will likely be another service implemented on
top of this KMS uber-project. Berin, am I wrong?
> KM in my perspective is something which can be
> supported by such technology, but is not a technology by its own.
Correct. As I said in a previous email, I want a toolbox, not a finished
and boxed software product. Something that gives me the pieces that I
can compose as my needs request.
This is also a safe business model for this list: by building components
that cannot be sold directly without additional customization work, we
are not going to compete on the software, but on the services, thus
avoiding the creation of commercial friction on this list. (unlike it
happens on projects like GNOME for Ximian involvement)
> By massaging & managing the many carefully crafted but sometimes hard to digest RT's
> into such KM-supporting technology, more people will be able to collaborate better on
> big, beautiful but complicated projects such as cocoon.
Granted and understood. I'll try to coordinate this R&D process in a
more coherent and understandable form. Hopefully, results will pay off
this effort :)
> Jummy... fun times ahead!
I really hope so.
--
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: [Summary] Dreams, RTs and getting the stuff done
Posted by Steven Noels <st...@outerthought.org>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: woensdag 5 december 2001 20:16
> To: Apache Cocoon
> Subject: [Summary] Dreams, RTs and getting the stuff done
>
>
> I've been having a private conversation from somebody on the list that
> 'suggested' that we should focus on something and getting it done rather
> than dreaming on many things and dilute our effort.
here's 'somebody' - perhaps we should mention that it started off with severe mutual
misunderstandings & subsequent impoliteness ;-)
> Stream of Thought #2: The perfect KMS
> -------------------------------------
>
> KMS stands for "knowledge management system". It's a marketing buzzword
> that indicates systems (mostly targetted for intranet use) that are
> capable of managing and making available 'corporate knowledge', the
> company information, in such a way that it's easily created, easily
> published and easily accessible.
>
> A typical KMS is composed of:
>
> 1) a front-end
> 2) a back-end
> 3) a content-editing system
> 4) a search engine
> 5) an administration toolkit
>
> the idea is to come up with solid and open software solutions that
> implement all the above key pieces, then sell the service to glue them
> together for customer needs.
>
> The map between those pieces and existing software is *far* from being
> accomplished but we are heading in the right direction.
To conclude our private conversation: a KMS should *at least* be able to facilitate &
support the cycle you mention above:
+-> research ----> develop ---> produce ----> use --+
| |
+---------------------- report ----------------------+
and as such is likely to have some overlaps with the d-haven.org/docoport dream
mentioned earlier on this list. KM in my perspective is something which can be
supported by such technology, but is not a technology by its own.
By massaging & managing the many carefully crafted but sometimes hard to digest RT's
into such KM-supporting technology, more people will be able to collaborate better on
big, beautiful but complicated projects such as cocoon.
Jummy... fun times ahead!
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org