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/
|