cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 20:58:19 GMT
donaldp@mad.scientist.com wrote:
> 
> On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> > I disagree.
> 
> :P
> 
> > The sitemap maps "resources" to "instructions to produce them".
> 
> it has the potential to - but it doesn't now from what I can
> tell (thou I may be wrong).

I need examples to say if the functionality is there or not. So far,
nobody came with something that was not possible to do in the sitemap...
and without bad hacks.

> > The Cocoon Sitemap is a "module-oriented programming languages for web
> > sites".
> 
> > > So what I see cocoons main strength is building the pipeline and "running"
it.
> >
> > I agree here, but I do NOT see why this matches with "publishing" only.
> 
> it doesn't. It is perfectly capable of building complex
> aggregating web-applications - but it aint easy to do it in
> it - thats what I am getting at.

Oh, we strongly agree then: my goal is to make this both technologically
possible without hacks, simple for simple stuff, complex for complex
stuff, but still possible for incredibly complex stuff.

And keep clean separation of concern and don't hurt scalability both
technical and human.

If you have a better plan, please, let me know.
 
> > > There are other requirements for a complete web-development system, two of
> > > which are aggregation and application logic.
> >
> > Correct. I agree with this separation but unlike you, I see cocoon below
> > both, not at the same level. Aggregation is a special way of generating
> > content, while application logic is a complex yet specific way of
> > building sitemaps and the logic that glues different resources together
> > depending on user actions or enviornment parameters.
> 
> I see cocoon below aggregation but at same level as
> application logic. Both IMHO should be side by side but each
> to their own :P

I disagree: you can place Cocoon into Turbine screens and you can use
Turbine services in Cocoon XSPs... but both are hacks. Big time hacks,
and I hate hacks, you all know that.

The only possible way to do side-by-side things is with modular
frameworks and I'm sure you agree with me on this :-)

> > > Aggregation means the method through which multiple pipelines are merged to
> > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > multiple outputs but no support for multiple pipelines producing one
> > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > it is not easy).
> >
> > ???
> >
> > Do you seriously think that something like this
> >
> >  <page>
> >   <sitebar xinclude:href="/sitebar"/>
> >   <body>
> >    blah blah
> >   </body>
> >  </page>
> >
> > is too hard to use?
> 
> now make that include variable depending on what *mode* you
> are in. ie Admins have different sitebar, people outside
> company have different colors/skinning, and admins outside
> company have both applied. ALso make it variable content
> depending on time of day etc etc .
> 
> It is all possible - but it is just not easy.

Granted. What I'm asking is to join effort to make it easier. And this
means working side by side with the Turbine people as well, I'm not
trying to reinvent the wheel.

> > > Aggregation will be served by Jetspeed (an apache project that is currently
> > > at java.apache.org but will soon be at xml.apache.org). Jetspeed does a lot
> > > more than aggregate - it mixes in lots of other options.
> >
> > Agreed. The goal is: Cocoon2 provides internal aggregation capabilities,
> > Jetspeed drives the process.... it's more or less a Cocoon Web
> > Application that uses its capabilities for a more specific purpose
> > (which is creating portals and bring different informative source to the
> > same site).
> >
> > I picture Jetspeed2 as a number of additional Cocoon sitemap components
> > and some sitemaps prebuilt do mix them together. Everything down below
> > is done by Cocoon, so you either can use Jetspeed or rewrite your own
> > with Cocoon functionality.
> 
> yep agreed.
> 
> > > Web-application logic is something different again - it includes all the
> > > "doing" aspects of the system. So if your applications contacts a database
> > > and performs a whole heap of transactions, performs complex processing etc
> > > then this should be done in web-application level. Apache has a
> > > web-application framework (Turbine at java.apache.org) that includes a lot
> > > of this functionality (Identity management, authentication, authorisation,
> > > database pools, "actions" etc).
> >
> > Yes, we need to integrate Turbine functionality in C2 and I have a
> > couple of ideas on how to do this:
> >
> > 1) get turbine-like services from Avalon (db pool, identity manager,
> > etc...) as blocks
> 
> thats what I am aiming for :P

See, we do agree deeply inside :)
 
> > 2) create a "web application language" that defines the logic of the web
> > application. This is then "compiled" into sitemap and XSP skeletons.
> 
> I always dislike this approach. I really don't like
> reinventing the wheel - even if it is a slightly better
> wheel. If I want to develope stuff for a large website with
> a lot of application logic I want to do it in straight java
> and not worry about anything else. If there was a way of
> scripting inputs to actions and templating outputs via some
> xsp sheet then brilliant - just don't make me use some ugly
> xml/java/scripting cross :P

I won't, don't worry. I totally dislike placing java into XML as well,
XSP was designed to be the very low level that users should never see or
use themselves... but you need taglibs for that and it's an evolutionary
process that takes time.

And calling java methods from XSLT extentions or using WebMacro like
templating is not a better solution either, since all have pros and
cons. There is no silver bullet.
 
> > Turbine is indeed cool, but it's programmer focused and our pyramid of
> > concerns doesn't fit to their model where the programmer is also the
> > site manager (which is never the case).
> 
> agreed.
> 
> > > So in effect when a request comes in it goes via a "sitemap" (not to be
> > > confused with C2s sitemap) that maps request to a web-application. The
> > > web-application does it's stuff and then chooses a C2 pipeline to output
> > > via. It then fills a "context" with relevent information (like result data)
> > > and executes the pipeline with relevent context. Aggregator sits on top of
> > > this.
> >
> > More or less, this is still unclear to me...
> 
> You seem to get everything except perhaps how contexts are
> filled with data from web-applications ?
> 
> Basically you put data in a context and this is used by
> various stages in pipeline.
> 
> For instance a request comes in and is mapped to a
> particular action. The action may do any number of things
> which result in it putting data in it's context. The
> context-data is then used at various stages in pipeline. For
> instance a username and address may be stored in the
> context-data. This is then pulled out at a generator or
> transformer stage. In many ways it is like "session" data
> per-request (yes that is a contradiction of terms :P).

Ok, I see your point.
 
> It is especially useful in templating style web-applications
> and I suspect in C2 aswell.
> 
> Context-data can also contain special "escape" commands that
> tell the C2 engine to do other things.
> 
> For instance the sitemap may pass incoming data down one
> action path - the path may result in one of 5 outwards bound
> publishing pipelines. The action can place magic-data
> in context to say which pipeline to choose etc.
> 
> Does that make any sense ? :P

Yes, but there is a problem with your vision: pipelines are _not_ chains
of actions. You cannot (and should not) have run-time pipeline
composition, otherwise the whole sitemap model falls apart.

The Turbine-like functionality can be perfectly stored into a complex
generator and leave the pipeline untouched.

This enforces separation of concerns between action programmers and site
administration (for example, you can change the layout of your web
application without messing with the web-app logic)

> > > None of these applications are yet easy to use with cocoon. I have been
> > > trying to get people to adopt diferent apache products for a while but so
> > > far I have only got them to se cocoon out of these three.
> >
> > I wonder why? :)
> 
> :P
> 
> well it is not what you think - I think cocoon is probably
> THE leading publishing framework - I am not even familiar
> with any comparable products - but the people I got to use
> it just love it because it is easy to use (at least compared
> to other OS frameworks) and lets them do what they want
> (basically publishing from a db)

This is what I was aiming at: Cocoon does what you need and evolves with
your needs.

This is why started with static publishing, then dynamic publishing, now
complex dynamic publishing and in the future very complex dynamic
publishing.

It's all about placing information on a user browser after all.

It just gets more tricky as you add complexity.
 
> > More or less, I agree. But I do not see why Cocoon2 can't fit all of
> > them in fuctionality. Don't get me wrong, it's indeed hard to write web
> > applications on C2 "today"... but the functionality you need it's
> > there.. we just have to "tune it" for web applications and create
> > helpers for you.
> 
> yep. It is possible - just not easy and I have not seen any
> discussion about action-orientated processing.

Agreed, but you seem to imply with your mail that action-orientated
processing is not of our concern.. which is, indeed, not the case... we
just want to finish up the core before doing anything inside sitemap
components.

And, yes, it might turn out that the sitemap needs new semantics to
drive this... so what, we'll add it... adding things is not a problem,
the problem is removing things.

This is why you make just one step at a time.

> I saw a while
> back that someone was discussing form validation but that is
> only a small part of picture.

Please, don't use the "it doesn't do it today" argument around here:
many of the specifications we are using (and we use a lot of new ones!)
are not even finalized and we are busy trying to get ready with a first
beta release...

Proposing is good and welcome, but please, understand the dynamics of
this project.
 
> > > >And, if Cocoon isn't a web-app framework,
> > > >are there any web-app frameworks it'll integrate with easily?
> > >
> > > Well currently Jetspeed does it and it wouldn't be hard to add it to
> > > turbine. The problem is that neither is yet easy to set up and they require
> > > a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> > > that is the way to go.
> >
> > I don't think it's possible to integrate turbine and Cocoon. They are
> > too different. But Cocoon can clone Turbine functionality and provide
> > better separation of concerns.
> 
> actually I demo-ed cocoon pages in turbine a bit back to try
> and entice people to use turbine (they already used
> cocoon) but they disliked the difficulty of setting it
> up. It was also a major code-hack :(

I know.. the problem is that Turbine folks don't think it's a hack and
they even suggest it to users.
 
> > > If you have a product out in next few months just write xsp to do it for
> > > you - if your product timeline is longer (end of next year) then doing it
> > > the *right* way may be in order. I am trying at the moment to get some
> > > funding to setup an integrated solution and if so will start an OS frontend
> > > next march. Heres hoping :P
> >
> > Well, that will clearly fork this project then, since we'll be aiming at
> > the same target :)
> 
> hmm - Perhaps I should just wait and see :P

No, you should get your hand dirty and make proposals. This is what
you've done in Avalon and it worked well, didn't it? When you have time
and energy you should do the same here to scratch your itches.
 
> A few questions thou -
> 
> * in the future do you plan to be able to map incoming
> requests to event mosaics ?

Sorry, doesn't parse.

> * will sitemap be able to represent other aspects of system
> (like I mentioned a while back on Avalon list ?)

Same here, please, give me more context.
 
> From reading the code I was under the impression that is
> publishing orientated and from a few comments here I was
> under the same impression (which could quite possibly be
> completely wrong as I don't always pay attention :P)

There is no web application that doesn't publish information, while
there are publishing necessities that don't require the complexity of
web applications.

This is my personal vision of the web. And Cocoon reflects this starting
from publishing functionalities and growing bigger to match all possible
publishing needs, even mapped by complex logic.

But it's an evolutionary process and will take time and help to happen.

No, Paul, we are not focused on publishing *only*, but publishing has a
central role on the web and still will in the future (even more than
today).

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



Mime
View raw message