Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3938F99E.F26457A@apache.org>
Date: Sat, 03 Jun 2000 14:27:10 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Cocoon and Jetspeed
References: <2ECFE9456D0F6A4FA77B38C25AAE230918EB@the.one.lv>
 <39344C73.DF494436@apache.org> <393860A9.B828EF8@relativity.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

burtonator wrote:

> > > I agree about the complexity and failing. It could be turned off by
> > > default and static file used instead... However, I think it would be a
> > > powerful option to have...
> >
> > Cocoon doesn't fail. Period. That's _NEVER_ an option.
> >
> > It's like implementing an HTTP server on your servlet just in case
> > JServ/Tomcat stalls. That's plain silly.
> 
> Huh?  I never said that.  Certain things are just done different.  This
> doesn't mean they are "wrong".  Just different.

That's not what I read above.
 
> <snip>
> > > > needed.  I am also want to merge something we have at Excite called
> > > > GenAPI what should make all this easier.  IE Stay Tuned :)
> >
> > That the point! JetSpeed is an XML web application and should remain so.
> > You are adding more and more technologies that should reside at Cocoon
> > level. You should just _use_ them.
> 
> Yes.  Cocoon or Turbine.  There are already features I have added to
> Turbine because I have needed them and I have submitted misc pathes here
> too.

Sure.
 
> > Database persistance of XML documents is something that _everyone_ is
> > likely to need pretty soon in the server side world, not just JetSpeed.
> > Mixing this API with JetSpeed would require people to jump thru loops in
> > order to achieve that.
> >
> > I don't think that's your goal.
> 
> I never said this would be part of Jetspeed.  Actually what I am trying
> to accomplish is something that everyone can use.  I don't care where
> this ends up, Turbine, Cocoon, its own project.  I just want the code :)

I understand, but sometimes you need to take it easy and do a little
design before jumping to your editor.

I don't enjoy coding and you can clearly tell from any code I wrote. But
you seem to like coding a lot :)
 
> > > Have you looked at prowler (available at ftp://www.softwarebuero.de)?
> > > >From the information that I have got, it is trying to achieve very
> > > similar goal... to provide common java api to heterogeneous information
> > > sources...
> > > (I'm not aware of the licencing issues, though)
> > >
> > > > User personalization will be achieved with XSP.  Just a little
> > > > different.  We can go into this in depth if you want.
> > >
> > > I would love to hear what your ideas are on this...
> >
> > Same here...
> 
> Just a UI on top of PSML that is based on XSP.  The PSML would be
> transformed into XHTML and would allow you to configure your own PSML
> file.
> 
> > > > You can do this now.  It just isn't implemented anywhere.  I think
> > > > multiple customized pages is important.  IE I want an 'Open
> > > > Source' and then a 'World News' page
> > >
> > > how? As much as I have understood, the PSML files are very _static_
> > > currently... I cannot make "semi-personalized" pages, or can I?
> > >
> > > > The sitation should be a little different.  Mainly because of
> > > > subscription support.  If someone comes from a WAP device and wants to
> > > > create a customized page, Jetspeed needs to do some
> > > > introspection to see
> > > > which portlets the user can subscribe to (IE an HTML and WAP don't
> > > > mix).
> >
> > No!!!! Cocoon will do it for you, that's the point!
> >
> > Cocoon will provide services for creating your site using components.
> > JetSpeed should be a collection of components with some out-of-the-box
> > glue to install them and see them working. But Cocoon should be the
> > engine behind it that drives all the components in the right places at
> > the right time.
> 
> ug.  NONE of this is implemented yet or even thought out!  Just because
> I say Jetspeed will do this doesn't mean that Cocoon won't be used!

Ok, just to be sure.
 
> > > Yep, I was thinking about this also, but I just didn't want to make my
> > > email any longer than it already was.
> > > One solution would be that portlets would store their stylesheet
> > > references in registry, so it would be obvious which ones support which
> > > media. However, this could centralize the administrative work (less an
> > > issue in the case of cascading registry).
> >
> <snip>
> > Maybe on the jetspeed list, but I don't think you are a minority around
> > here...
> 
> Whatever.

There's no reason to be harsh, we are trying to help with the
integration. I said "maybe" because I don't know. I was not presuming
anything...
 
> > > Then again, if we could drop the support for everything else than
> > > cocoon, I think that would reduce the complexity... but we wouldn't lose
> > > anything in functionality, only gain... (OK-OK, I'm just speculating
> > > here ;-)
> <snip>
> > JetSpeed then can be just a sitemap/configuration, a collection of
> > logical components and a bunch of static pages. And you can concentrate
> > in making your web-app more usable and powerful from a user perspective,
> > rather than from a logic perspective, since you reuse all the logic and
> > separation design patterns that Cocoon was designed upon.
> 
> The goals are to move in this direction.

Great, this is what I wanted to hear. Plain and simple.
 
> <snip>
> > > But I'm still uneasy about putting in "dumb" CDATA sections... I would
> > > rather leave this job totally to serializers. But I understand that this
> > > wouldn't be possible if we want to support writing portlets with
> > > webmacro for example.
> >
> > Of course, you loose something moving from Turbine into Cocoon, but what
> > you gain is, IMO, worth the effort and the changes.
> 
> I don't like this ProjectX vs ProjectY format of this thread.
> 
> Jetspeed will ALWAYS run with Turbine and Cocoon.  We won't be getting
> rid of either one for any time soon.  Each has its advantage.
> 
> Turbine handles the logic backend, Cocoon should handle the
> presentation, Jetspeed should handle the data.

I'd love to be able to do this. Unfortunately, I still have to see a
valid proposal for this.

> <snip>
> > Again something that Cocoon already does with XInclude (or, at least,
> > plans to do in the near future).
> >
> > Please, don't get me wrong: I think JetSpeed has great potential to
> > become _the_ XML-web-application everyone will use on their web sites
> > for both personal and business use.
> >
> > On the other hand, I think Kevin is simply following the wrong path that
> > leads to merging Turbine and content syndacation, something that I
> > consider a hack since Turbine was _not_ designed with this in mind (I
> > don't agree with Jon on the orthogonality of the two issues).
> 
> I think you are viewing Turbine from the perspective of content.  The
> Screens/Navigations etc can be done much better without code!  It should
> be XML only.  I want to use Turbine for the backend features (database
> pooling, etc)

Ok.
 
> > I belive JetSpeed would make the right use of Cocoon2 functionality
> > allowing you to concentrate in providing more features to your web-app
> > rather than cloning services that Cocoon2 already implements.
> 
> yes.
> 
> > The price for this will be to refactor JetSpeed to base it on the Cocoon
> > framework.
> 
> yes.
> 
> > I see this as the only future-compatible solution... otherwise, you
> > might well see people tearing apart your project and porting the useful
> > pieces over to Cocoon... which will be very sad :/
> 
> Yeah.  That would be me.  :) Read ./docs/TODO.  Cocoon 2.0 is great.
> But you don't see me talking about Jetspeed 1.3 all the time because the
> code isn't done.  All these issues will be addressed.

Period, then.

No more venting. We appear to be in _strong_ agreement and this cannot
be harmful to anybody.

Also, if JetSpeed designes a clean way to integrate Turbine and Cocoon,
I'll be the first one to be happy about it. And I'm totally serious
about this.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------