Berin Loritsch wrote:
>
> There is a lot to discuss, and I will try to rim the fat as I go along. First,
> let me say that having you back, Stefano, is great!
Well, thanks buddy :)
> With a little iron sharpening
> iron, we will have an excellent tool.
You can bet your ass on that :) [excuse my french and no offense to
frech people out there :)]
> > > Automatic discovery and deployment of Cocoon webapps requires
> > > that we allow our URI space to be at the mercy of your deployment tool.
> >
> > This is where I disagree.
> >
> > I never used the word "automatic" because what I described (not even
> > proposed, just thrown out as a RT to bootstrap a discussion) is a system
> > that allows you to install web applications in a manner which is
> > (presumably) more friendly than the rough and undesigned way we do today
> > that follows the implicit assumptions that Servlet API make that one WAR
> > file = one web application.
>
> Ok. I can agree with that statement. Keep in mind that for Cocoon
> app installation you have to modify both the unarchived war and the
> archived war file. The reason is that SOME servlet containers ignore
> the original war file once it is deployed. SOME servlet containers
> overwrite the contents of the directory with the contents of the war
> file. And still OTHERS act like the second scenario until the unarchived
> directory is modified.
>
> Don't you just love it when there is no standard?
We have more than one Apache members listed on the JCP 053 which is
responsible for the creation of that spec. If you think it's important
to specify what behavior the servlet container should take when
deploying a webapp, please, let's discuss a formal proposal that we
might submit to the group and that might make into Servlet 2.4
> > > It is the same flaw in WAR files.
> >
> > Again, I disagree: the only flaw I see in WAR files is the implicit
> > one2one assumption I stated above and the fact that deployment behavior
> > is mostly left to the "mercy of your servlet container" (to quote you).
> >
> > I'm not describing a solution that copies over these bad assumptions,
> > but one solution that takes the good out of the war file concept
> > (mostly, the ability to install a package, just as you install software
> > on your machine, instead of having to place a bunch of files here and
> > there and mofify a ton of configurations just to make it start, not
> > talking about coherence between the different webapps installed in the
> > same system)
>
> Ok. I have some ideas on the requirements of such a system. For one thing,
> the hierarchical CM approach will have to be used.
Ok
> > > Yet another issue arrizing from the URI space issue is where
> > > to locate all your images and resources. I prefer to have one URI for each
> > > resource, wether it be image or stylesheet. I can't reference an image at
> > > "/images/foo.jpg" because my webapp or cocoonapp may not be installed at
> > > the root context. There really is no way of automatically rewritting the
> > > location to reference the context root. What I end up doing is writting
> > > a rule in my sitemap that makes "images/foo.jpg" read the same resource
> > > no matter what directory it is called from--effectively poluting my URI
> > > space.
> >
> > I've always been an avid proponent of the complete remounting facility
> > of subsitemaps that lead to the assumptions that all URIs are relative
> > to the current sitemap and absolute locations were not possible.
>
> Yes, but one issue is that stylesheets which are clearly in the webapp
> context cannot be accessed by a subsitemap if it requires parent directory
> access. This is not optimal. As to your proposal below, there is a lot
> to like. Lets see if we can come up with a killer.
>
> > While the ability to perform internal redirection makes is possible to
> > do what you describe above, I came to agree that this is *not* a good
> > thing and does not improve any concern separation nor makes the
> > architecture more elegant.
> >
> > As you imply, rather the opposite.
> >
> > Expecially thinking about batch processing, such remapped resources
> > would end up being copied all over the place with a clear inelegance,
> > redundancy and memory consumption.
>
> Just look at Avalon's documentation build process to prove that.
>
> > I'm happy to reconsider the ability to mount absolute URIs in sitemaps.
> > (of course, absolute is used here in sense of global cocoon context, not
> > absolute compared to the entire web site space)
>
> That is what I am referring to. As of Servlet 2.3 and much debate, the
> official stance on where "/resource" maps you is to the web server root,
> not the context root. Instead, the context root is much more difficult
> to reach. Perhaps we can improve the HTML serializer to automagically
> correct context root resources.
Yuck! I'd hate that. Serializers that mangle things behind your back are
the worst pain in the ass to find out expecially because you never look
at them since you normally consider them brainless and pure adapters
from the XML world to the binary world.
Let's find a more elegant way.
> > > Another side affect of the sitemap is that you cannot refer to resources in
> > > a parent sitemap. The whole concept is centered arround the resources being
> > > in the same directory as the sitemap, or below. I find this frustrating,
> > > as I am forced to duplicate resources in my directory hierarchy just so the
> > > entire site can have the same look and feel.
> >
> > Careful, this is an entirely different story. While I agree that having
> > the ability to access absolute Cocoon URIs is a good thing, I still
> > believe that something like cocoon:../images/logo is *bad* because it
> > removes the ability to remount the subsitemap.
>
> Let me expound. I like to use a dierectory structure like this:
>
> /xdocs
> /resources
> /images
> /scripts
> /styles
> /stylesheets
> /system
> /WEB-INF
> /logicsheets
> /cocoon.xconf
> /logkit.xconf
> /sitemap.xmap
> /${sub.app}
> /xdocs
> /resources
> /images
> /scripts
> /sitemap.xmap
>
> The problem is when I want a consistent look and feel in my ${sub.app}
> area. I cannot access the /stylesheets that are accessible via the
> context--but not via the sitemap. This requires me to copy the
> /stylesheets to the ${sub.app}.
Ok, in this case, absolute URI would work and will not require you
access to your parent, but to an absolute location (which, in this case,
accidentally, happens to be your parent)
This is a simple fix and we can schedule it for Cocoon 2.1 since it
might break back compatibility of sitemaps a little.
> > So, while the three other URIs (absolute and the two equivalent local)
> > maintain the same state independent on their relative position, the
> > "parent referring" one does not.
> >
> > This is why it should *not* be available, unless we want to sacrifice
> > control over webapp remounting and give it to the user. Something I'd
> > rather *not* do, but not because I don't trust users' ability to manager
> > their URI space, but because they can become so complex that breaking
> > transparent remounting at the architectural level places more concerns
> > on the URI space maintainer and for sure he'll have enough to take care
> > of.
>
> Hopefully I explained the scenario better further up. Resource is a very
> generic term, and does not always refer to graphics.
>
> > > Clearly, Cocoon needs to focus on some key resource resolution issues to
> > > make it work properly. Part of the issues come from resolving the names.
> > > Perhaps views are our ticket to standard look and feel. However the site
> > > maintainer needs the perogative of adjusting the look and feel of the site
> > > without affecting the logic of the site.
> >
> > Of course.
> >
> > I just had an idea: could avalon-like component behavioral dependancies
> > for cocoon webapps make this possible?
>
> Actually I was thinking along these lines. (Great minds really do think
> alike).
great mind? nah, just obsessed by architectural elegance :)
> > I explain further: think of cocoon webapps as avalon components. Your
> > image gallery webapp and your webmail webapp being instances of
> > behavioral descriptions for webapps (sort of "interfaces" for web
> > applications) and both require the instance of another webapp which
> > includes the stylesheets they need to complete their job.
> >
> > So, the contract is that, in order to work, these webapps *require* the
> > existance of the stylesheet webapp and they require to know how to
> > access it.
> >
> > One solution is absolute positioning: the stylesheet-containing webapp,
> > must be mounted in a specific place. But, this is ugly and might create
> > collisions, expecially if different versions of the webapp must be
> > installed (one webapp requires one version and another requires
> > another).
> >
> > The other solution is to use the same avalon component discovery
> > mechanisms: if the package instance of the behavioral interface
> > "Gallery" requires one package instance intalled of the behavioral
> > interface "Style", it might use something like
> >
> > cocoon://Style/stylesheet/images2html.xslt
> >
> > which allows three different behaviors:
> >
> > cocoon:/images/logo -> absolute positioning
> > coocon:images/logo -> relative positioning
> > coocon://Look&Feel/images/logo -> role-based positioning
> >
> > that, IMO, satisfy all needs and make the entire thing *extremely*
> > elegant.
>
> I know what you are saying, but I think we can make it a bit better.
Oh, that's for sure.
> In the proposal I had back in July (link in another email), I was
> thinking about resource naming. That way, no matter what sitemap
> or URI map a resource was, it could be found. This was as a result
> of trying to implement the subsitemap approach with sub applications.
Ok, this is a similar but different solution to allow more indirect
addressing.
> I ran into the problem with sitemaps at that point where I could not
> access my stylesheets. I figured if I could name a view resource,
> I could use that resource in every sub application. The FlowMap would
> be used for form progressions, and itself be considered a resource.
Good point.
> Because Cocoon is an XML framework, in order for this approach to work,
> you have to define the interfaces. There are definite roles that I
> have already identified. Some of the solutions come from concepts in
> SOAP, and some of the solutions come from concepts in JNDI, but here goes.
>
> For sub applications to work, you must have them work to a specific schema.
> (this concept is from SOAP). For instance, your resource must return
> the results in DocBook format so that the parent knows how to apply views.
> This is the interface of your "component".
I've already thought about this when I thought about a way to validate
sitemaps and it's a *LOT* more complex than this.
Let's make an example: the "behavioral interfaces" of pipeline
components are the expected input namespaces and the resulting
namespaces. But listing them is not enough: you must know the exact
structure, thus the namespace-aware schemas.
Even between components, schemas are the structure description that
identify the expected "shape" of the SAX pipe that connects two
components.
Now, suppose you have a pipeline such as
<g] -> [t1] -> [t2] -> [s>
and you have
g -> output schema of generator
t1i -> input schema of first transformer
t1o -> output schema of first transformer
t2i -> input schema of second transformer
t2o -> output schema of second transformer
s -> input schema of serializer
with all this information you can precisely estimate if the pipeline is
"valid", in a behavioral sense.
This would allow you to perform some pretests on sitemaps (before
compilation and before uploading) that avoids those "impedence
mismatches" between connected components.
As more and more Cocoon components emerge and are made available even
outside the Cocoon distribution, the ability to estimate the "behavioral
match" between two components, will very likely be vital, expecially for
sitemap authoring tools.
The algorithm that performs the validation is far from being trivial: a
sufficient condition (and the most simple one) requires the connecting
ends to be identified by the exact same schema.
So, the above pipeline would be valid *if*
t1i == g
t2i == t1o
s == t2o
but this is not a necessary condition since there exist cases where a
pipeline is behaviorally valid even if the two subsequent schemas don't
match completely, but only on parts.
In fact, the input schema might work only on part of the previous output
schema, for example, working only on one namespace and leaving the
others elements pass-thru unchanged.
But in this case, in order to be possible to continue the validation,
the output schema must state what can be left pass thru.
I don't want to get deeper into these details, but I just wanted to show
you that establishing behavioral composition on pipeline components is a
lot more complex than you described.
But, yes, it can and needs to be done.
> Second, there are roles that
> are identified in the sitemap and the flow/uri map concepts:
>
> Views: Take a known schema and transform it into a final product (HTML,
> PDF, XML, etc.). It is assumed that a View completes the pipeline
> all the way to a Serializer.
>
> Resources: Take any source and transform it into a known schema. It is
> assumed that the resource starts the pipeline from Generator.
> There are specializations of this type.
>
> AdatableResource: A specialization of Resource where the output schema
> can be specified by the parent. I.e. If the parent
> doesn't know the inbox schema, the Adaptable resource
> will convert it to the docuement schema.
I had the same feeling when first writing the sitemap when I ended up
writing all my stylesheets as xml2html.xsl or simple-docbook2fo.xsl and
such. I thought: couldn't the sitemap automagically assemble the steps
to adapt one component to the next without me to know every simple
transformation stylesheet?
In fact, stylesheets are nothing about style: they transform one schema
into another which is more suitable for your needs.
So, I perfectly see what you are aiming at, but at that time, I just
wanted something that worked and, as you very well know, the sitemap is
already complex enough :)
> StreamResources: Take any source and goes completely through serialization.
> This is basically an alternate for Readers, although it
> can also be used for generated reports.
>
> FlowResources: A mounted flowmap that performs all the logic necessary for
> a complex form. It handles paging, etc. It is a type of
> compound resource in that it pools several simple resources
> together, and returns the one we are concerned with at the
> moment.
>
> URIMapResources: A compound resource that maps URIs to specific simple
> resources.
>
> SitemapResource: A compound resource that is a sub sitemap. Sitemaps are
> completely self contained, so it is near impossible to
> override their results.
I'm not sure about these, though. Could you give me some pseudo-example
of a pseudo-sitemap and how it would use the above?
> A sub application can specify resource adaptors for it's native XML generators,
> for instance you might have a document schema and a schema for an inbox.
> The If the parent has a View that recognizes the inbox schema, then it will
> directly use that schema. If not, the sub application will specify a default
> mapping.
>
> Hopefully this is enough to get us started.
I understand very well the concept of schema-based adaptation, but I
think I lost you on the other resources, I think a couple of dirty
examples will get me closer to your point.
> > Agreed, do you think that my proposed avalon-like component solution for
> > webapps might help in this regard?
>
> definitely.
Good, does anybody disagree?
> > In short, you are asking for more solid and wiser contracts between web
> > applications and I believe that an absolute URI space accessing is
> > already a solid contract, but the proposed role-based addressing is a
> > killer since it allows strong contracts and still complete flexibility
> > and scalability.
>
> Yep. Well defined contracts reduce cognitive dissonence. Too many contracts
> increase cognitive dissonence.
Careful about using that term: "cognitive dissonance" is a good thing on
many situations since modern learning theories give it the role of
difference maker between short term and long term learning.
In fact, they suggest that something gets learned only when there is
cognitive dissonance and your brain must work to overcome it, normally
by creating the abstraction that make it possible to make the two
cognitive concepts resonate and overlap with your existing semantic
environment.
> In other words, I want our new contracts to be built on existing contracts
> and known principals so that it doesn't take as long for someone to come
> up to speed.
I totally agree with the cognitive concept behind this.
Cocoon was engineered with usability in mind: in fact, Cocoon itself was
created to allow separation of concerns at the use level and make it
possible for people to do their job better and with less overlap and
frustration.
I'd love to continue research on this topic by letting practical things
like real-life user experience as well as more theorical things like
cognitive science influence our decisions on how to make this project
evolve.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
