cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <u....@cbim.it>
Subject Re: Proposal: Inclusion of CocoBlog in scratchpad
Date Thu, 08 Aug 2002 08:37:44 GMT
I wrote:

 > I'd like to propose the inclusion of my blogging tool, CocoBlog, in
 > the scratchpad of Cocoon 2.1.

Some comments started coming in. I'd like to reply to all of them in a 
single message.

Vadim:

 > 1. What will prevent it from running in C203?
 > 2. Will there be option to switch back to xindice? AFAIK, xindice guys
 > have come up with embedded xindice, so it will be possible to embed it
 > as currently hsqldb is embedded.

1) The current code should run on 2.0.3, but I haven't tested it. If we 
decide to use the authentication framework, however, maybe it will have 
to be backported to 2.0.3 too.

2) I decided to temporarily abandon Xindice because it lacked some 
features that I needed. The transition from Xindice 1.0 to 1.1 (or is it 
2.0?) looks like it will be an almost complete rewrite and nobody knows 
how much it will take. Anyway, to support Xindice or any other data 
source, you just need to write a generator that provides RSS 1.0 data 
and an action that can store an XML document (XHTML now, other formats 
in the future) and some metadata (title, author, date, etc.) to the data 
store.

Michael:

 > I think it is very good that Cocoon is shipping examples, but I also
 > think that it is very
 > important to distinguish between an example and an "application" (or a
 > framework based on an application server or another framework).
[...]
 > To me a Blogging Tool such as CocoBlog is an application, or actually
 > rather a specific type
 > of "publication" based on a "content management framework" based on an
 > "application server".

I agree, in principle. This [1] is what I wrote some time ago when 
Matthew Langham suggested that I might "turn CocoBlog into components 
that are inside the Cocoon distribution":

	"All in all, I think inclusion in Cocoon is premature, to say
	the least. Maybe, if we had Cocoon blocks, we could think
	about it."

However, some other people seemed to think that it might have been a 
good idea, after all:

John Morrison: "Would you and Ugo (Cocoon Blog) consider adding these to
the cocoon samples? It would still be possible to build just them, but 
it would help other people with the tech..." [2].

Ivelin Ivanov: "Do you want to consider moving it to Cocoon scartchpad?" 
(private mail).

Tony Collen: "If the people speak, give them what they want :) Perhaps 
you could still keep the Cocoblog-specific stuff in CVS somewhere, minus 
all of the actual Cocoon code, ie, XSPs, etc." [3]

Sam Ruby: "why not a xml-cocoon-cocoblog (or more simply 
xml-cocoon-blog).  I'd +1 it, and can take care of all of the cvs 
permissions, etc." [4].

Matthew Langham, again: "The reason I commented on CocoBlog not being a 
part of Cocoon is the fact that I am not sure if I like the idea of lots 
of separate products that come complete with "some" version of Cocoon." 
(private mail)

This, in short, is the genesis of the current proposal.

Steven:

 > CocoBlog could be the prime example of a drop-in Cocoon application
 > (dare I say 'block'?). If we add it to the distribution, we miss the
 > opportunity of showing off plug&play installation of a Cocoon-based
 > app.

The problem is I don't see a real plug&play feature coming to Cocoon 
very soon. So we have tow options:

a) I continue to distribute CocoBlog as a full application that comes 
with its own Cocoon version, just like I'm doing on SourceForge
b) I distribute CocoBlog as a not-so-plug-and-play Cocoon "block" and 
leave it to users to plug it inside their copy of Cocoon.

What I'm proposing here instead is

c) we include CocoBlog in scratchpad and when we get blocks, we refactor 
it out.

But listen, I don't want to insist too much. As I write above, I have my 
own doubts about this move and own much of this proposal to the gentle 
pressure of the people I quoted.

Ovidiu:

 > I agree with Michael that we should keep Cocoblog as a standalone
 > application, not only an example for Cocoon. I would very much like 
to use
 > Cocoblog as my Weblog tool instead or MovableType, and I think we should
 > start a concerted effort to make this happen. I've taken a look at 
Cocoblog,
 > and I have my own ideas on what would make a good Weblog tool, so I 
think we
 > should definitely start talking about it.
 >
 > Setting up a separate project, either at Apache or Sourceforge, seems 
to me
 > like the best option for now.

Starting a new project at Apache will require going through the Apache 
PMC. As for SourceForge, I already have a project there [5], but it 
never really take off and form a community. This is the second reason 
for this proposal: since many cocooners are also bloggers, they might 
start using CocoBlog for real if they get it with their daily dose of CVS.

And yes, I realize, this is like saying: if you aren't going to download 
and install it yourself, I'm going to feed it to you. Or, in other 
words, if the mountain doesn't come to Mehemet, Mehmet will go to the 
mountain ;-)

Keep the comments coming in.

	Ugo


[1]: http://www.beblogging.com/blog/20020612-215555
[2]: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102327390831650&w=2
[3]: http://radio.weblogs.com/0100630/2002/06/14.html#a5
[4]: http://radio.weblogs.com/0101679/2002/06/13.html#a567
[5]: https://sourceforge.net/projects/cocoblog/

-- 
Ugo Cei - http://www.beblogging.com/blog/


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message