RE: Cocoon and Jetspeed

[Neeme Praks <ne...@one.lv>]

Sorry for such a delay in answering but my daily job kept me too
occupied to write any "in-depth" responses ;-)

> -----Original Message-----
> From: burtonator [mailto:burton@relativity.yi.org]
> Sent: Wednesday, May 31, 2000 12:07 AM
> To: cocoon-dev@xml.apache.org; jetspeed@list.working-dogs.com
> Subject: Re: Cocoon and Jetspeed
> 
> Basically an XSP app that takes in an existing PSML document 
> and renders
> a UI for it.   You would configure your PSML and then save it back to
> disk.  That is a lot less complicated than it really is.  It 
> is a large
> job but it needs to be done.

well, I think this makes things much less flexible. My suggestion would
still be to use cocoon when reading the personal PSML file: if you store
profiles in static files (as we have right now) you can use XSP (or
whatever other cocoon method ) to return them as they are; however, I
have the option to use XSP to generate the file from some other data
source instead.

How it could actually look like:
you have the default.psml file that is actually an XSP page. 
If anonymous user requests this page, XSP returns the default.psml file
from the filesystem.
If authenticated user requests this page, XSP returns the user personal
page from the filesystem (stored as username.psml, for example).

At the same time, this doesn't limit the developer to the default
storage (filesystem). Instead, I could replace the logic in the XSP to
get the data from database (or any other datastore) instead.

Simple and powerful, isn't it?

> No.  The engine is smart enough to handle static files that 
> change.  If
> you modify default.psml while Jetspeed is running it will rebuild your
> PSML page for you.

But I mean personalization-on-the-fly, not that I sometimes change the
file and the _all_ users see these changes. What I mean is that the
content is customized for _each_ individual user by the means of XSP
page.

>  We really just need to write a PSML 
> content provider
> and abstract its data representation so that you can use a 
> file or a DB.

well, then we would be limited to file and DB, until somebody adds some
other "content provider". As Stefano also pointed out, we could _reuse_
Cocoon's generating capabilities for this, instead of reinventing the
wheel...

> Do you mean the deployer?  I think that by default a Portlet 
> should have
> the capability to support certain media types but it is up to its
> deployment to determine if it can actually render these at runtime.

ok

> > (also goes together with the concept
> > of "remote portlets").
> 
> I didn't follow.

I mean the case of storing stylesheet ref's in the registry vs. storing
only capabilities in the registry and storing actual stylesheet ref's
with the portlet.
The second case is more preferable for the remote portlets idea: the
portlet resides on remote server and the owner of that portlet can
easily change the stylesheet ref's that are used for actual
transformation of the XML portlet into target media (and all the
Jetspeed servers that use that portlet would automatically update the
rendering logic). In the first case the owner would have to notify all
the Jetspeed servers that use his portlet about the change of
stylesheet.

> > So, the registry would store metadata about the portlet: 
> where to find
> > and how to access the portlet and what media types does it 
> support. Then
> > I would be up to the portlet developer to actually 
> implement the support
> > for these media types.
> 
> I see it the other way around, but yes.  

Other way around?

> > I mean, if I want to return SAX events instead of ECS 
> element, how can I
> > achieve that?
> 
> ClearElement.  You can put whatever you want in there.  This 
> is how the
> FileServerPortlet works, it just reads in any file and shoves 
> it into a ClearElement.

well, but here we arrive to the same problem of "dumb" string data: in
order to do any sensible post-processing, Cocoon would have to parse the
string (in ClearElement) and convert it to SAX events. Of course, this
is a problem only if we would want to do some post-processing on the
contents of ClearElement.

> > 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 ;-)
> 
> The other issue is the current Cocoon impl.  Honestly, the Cocoon
> integration isn't something that I am proud off.  It forces us to have
> RunData everywhere (which is a serious technical problem within the
> core, IE if you wish to kick of a Thread you need to bring the RunData
> with you :().  When Cocoon 2.0 ships (still 6 months away) we 
> will be in a better place but until then we are still in a kludgy env
:(

I also think that Cocoon 2 will be the version of Cocoon that I would
like to integrate Jetspeed with.
The time delay is of course a problem, but I think we can influence the
design of Cocoon 2 by taking the issue of integrating Jetspeed early in
the process.

Meanwhile I'll probably have to use the current state of Jetspeed to
deliver a beta version of the product I'm working on. And then port it
to Cocoon2/Jetspeed when it is finally there.

> > 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.
> 
> We could do schema validation on the resulting XML document.  
> IE PSML ->
> WAP Portlets -> combined WAP document -> schema validation.

well, but for this you would have to re-parse the CDATA sections...

> I thought this is what you were hinting at :) 
> 
> There is a document for doing this with JServ.  It really 
> should be done
> at the Servlet engine level.

ok, maybe. I'm not very familiar with servlet programming _yet_.

> There is a security hole here in that if I put some Javascript into my
> portlet and then cnn.com served a portlet from hacker.org, the
> hacker.org person could get passwords from cookies on the 
> cnn.com domain
> :(

Yes, that could be an issue... Then you would have to give the user a
_serious_ warning that this can be major security hole and that he
should only use portlets from trusted sources.

> Still an interesting idea though...  But maybe it should just be
> something like RSS or XMLRPC.  I mean essentially a Remote 
> Portlet would
> only be data communication and nothing else.  

But this takes away much of the simplicity and flexibility, doesn't it?
With remote portlets, a user could put together his own simple portlet
on his homepage by following a few quite simple rules... without a need
to learn the complex syntax of RSS or XMLRPC.

Neeme

Re: Cocoon and Jetspeed

[burtonator <bu...@relativity.yi.org>]

Neeme Praks wrote:
<snip> 
> well, I think this makes things much less flexible. My suggestion would
> still be to use cocoon when reading the personal PSML file: if you store
> profiles in static files (as we have right now) you can use XSP (or
> whatever other cocoon method ) to return them as they are; however, I
> have the option to use XSP to generate the file from some other data
> source instead.
> 
> How it could actually look like:
> you have the default.psml file that is actually an XSP page.
> If anonymous user requests this page, XSP returns the default.psml file
> from the filesystem.
> If authenticated user requests this page, XSP returns the user personal
> page from the filesystem (stored as username.psml, for example).
> 
> At the same time, this doesn't limit the developer to the default
> storage (filesystem). Instead, I could replace the logic in the XSP to
> get the data from database (or any other datastore) instead.
> 

Yeah.  I agree.  But it would be nice if we could just think of the
whole thing (filesystem or DB) as XML and then deal with it that way.  I
don't see why XML is involved.

> > No.  The engine is smart enough to handle static files that
> > change.  If
> > you modify default.psml while Jetspeed is running it will rebuild your
> > PSML page for you.
> 
> But I mean personalization-on-the-fly, not that I sometimes change the
> file and the _all_ users see these changes. What I mean is that the
> content is customized for _each_ individual user by the means of XSP
> page.

Yes.  This will work.  The XSP app just creates a new XML document
in-memory with castor and then writes it to disk.  Jetspeed is smart
enough to realized that the file has changed.
 
> >  We really just need to write a PSML
> > content provider
> > and abstract its data representation so that you can use a
> > file or a DB.
> 
> well, then we would be limited to file and DB, until somebody adds some
> other "content provider". As Stefano also pointed out, we could _reuse_
> Cocoon's generating capabilities for this, instead of reinventing the
> wheel...

fine.  At some point you need to hit the DB and this needs to be
abstracted.  Maybe Prowler is the solution... haven't looked at it yet
:(
 
<snip>
> > > I mean, if I want to return SAX events instead of ECS
> > element, how can I
> > > achieve that?
> >
> > ClearElement.  You can put whatever you want in there.  This
> > is how the
> > FileServerPortlet works, it just reads in any file and shoves
> > it into a ClearElement.
> 
> well, but here we arrive to the same problem of "dumb" string data: in
> order to do any sensible post-processing, Cocoon would have to parse the
> string (in ClearElement) and convert it to SAX events. Of course, this
> is a problem only if we would want to do some post-processing on the
> contents of ClearElement.

Well hopefully the ClearElement will be a valid document fragment (not
the DOM DocumentFragment) and it can snap into an XML schema (with
validation).  This is why it is important to pick the correct mime-type.
 
<snip>
> > The other issue is the current Cocoon impl.  Honestly, the Cocoon
> > integration isn't something that I am proud off.  It forces us to have
> > RunData everywhere (which is a serious technical problem within the
> > core, IE if you wish to kick of a Thread you need to bring the RunData
> > with you :().  When Cocoon 2.0 ships (still 6 months away) we
> > will be in a better place but until then we are still in a kludgy env
> :(
> 
> I also think that Cocoon 2 will be the version of Cocoon that I would
> like to integrate Jetspeed with.

yes.  It will be much better :)

> The time delay is of course a problem, but I think we can influence the
> design of Cocoon 2 by taking the issue of integrating Jetspeed early in
> the process.

Yeah.  I would agree.  If we do this it will probably be a while.  It
would have to go up for vote.  It could be possible to have a snap-in
cocoon implementation where you can select from Cocoon 1.7x or 2.0 but
this might be kludgy.  Certainly at some point it will be a requirement
to halt Jetspeed development and assure that the Cocoon 2.0 development
goes well.  I can't say when this will be though.
 
> Meanwhile I'll probably have to use the current state of Jetspeed to
> deliver a beta version of the product I'm working on. And then port it
> to Cocoon2/Jetspeed when it is finally there.

Hopefully sooner than later :)
 
> > > 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.
> >
> > We could do schema validation on the resulting XML document.
> > IE PSML ->
> > WAP Portlets -> combined WAP document -> schema validation.
> 
> well, but for this you would have to re-parse the CDATA sections...

yes.  True.  But in some situations they might not be parsed in the
first place.  Ex if you were to use Webmacro to write XML this wouldn't
be validated while it was produced so you wouldn't see a performance
hit.
 
<snip>
> > There is a security hole here in that if I put some Javascript into my
> > portlet and then cnn.com served a portlet from hacker.org, the
> > hacker.org person could get passwords from cookies on the
> > cnn.com domain
> > :(
> 
> Yes, that could be an issue... Then you would have to give the user a
> _serious_ warning that this can be major security hole and that he
> should only use portlets from trusted sources.

If we do a URI provider mechanism.  Then maybe remote portlets could be
done.  I am still -1 because you can do this with with the JVM.
 
<snip>
-- 
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN:  "Please Open Source Java!"
"For evil to win is for good men to do nothing."