cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] resource views, error handling, pipeline debugging
Date Sat, 01 Jul 2000 08:56:21 GMT
Niclas Hedhman wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > Niclas Hedhman wrote:
> >
> > > > > It is easy to see/define how a stream is split, but the hard part
is how is
> > > > > it joined back?
> > > > > And even worse, how is this detailed in the Sitemap??
> > > >
> > > > :-? Sorry, I don't understand you here.
> > >
> > > My issue right now is, where does the MetaData stream end up??
> >
> > On another view.
> 
> Hmmmm....
> Then I lost you again.
> I thought the MetaData stream was to accompany the Data stream with additional
> information, such as logging data, tracing and other information directly coupled to
> the processing of the main Data stream, No??

Yes, but it's not automatic it should be merged with the "data" output
stream.

> If not, then I fail to see the difference from ordinary data processing.

The difference is not technical but semantical.

> If yes, then the problem remains, because the the main data stream must still be
> processed as before, and sequencing is still a problem.

What do you mean with "sequencing"?
 
> > Then I went over all the optical modulation techniques used to transit
> > data as photons inside optical fibers (remember: this is what my day-job
> > is supposed to be).... and I came to the conclusion that "merging" the
> > two polarization planes is just one of the possible alternatives.
> 
> I think you need to see a doctor :o)  Lost it completely...
> Talk about applying a "Golden Hammer" far outside the problem domain.

Nah, this is just walking a long way in other fields to understand
design patterns applied and try to translate them in other domains.
 
> > Example: the "hyperlink" view contains information about hyperlinks
> > *only*.... but "browsable" contains both "semantics", "content",
> > "style", "hyperlinks", so "browsable" is not part of the base for this
> > solution space but it's formed with the combination of other "aspects"
> > of the resource.
> 
> Ok...
> 
> > So, when you are "requesting" a resource, you are "projecting" the
> > n-dimensional resource onto your m-dimensional window (the browser)
> > where n <= m.
> 
> I do?? I thought my window is 2D only ;o)

how blinding! :-)
 
> > For HTML, n = m. This is why there was no notion of this
> > "hyperprojection".
> 
> Right ?!?
> 
> > For XML, on the other hand, we have a technology that allows us to
> > separate the concerns on orthogonal planes, thus n <= m. If (n < m) we
> > are projecting and we end up loosing some information.
> 
> Ok, so far I follow. But fail to see the relevance.

Keep going, I should have told you I like walking :)
 
> > The idea reflects obvious geometrical behaviors: when you are projecting
> > a 3D space on a 2D view, you must "rotate" it to understand it's 3D
> > geometry. In fact, human visions indicates that it's enough to have 2 2D
> > snapshots from two different points to "estimate" the third dimension.
> > (stereography and psycoacustics are another of my hobbies)
> 
> Correct (sort of). But also don't forget that in the time-space equilibrium, time can
> not be neglected and in the case of your rotation (opposed to your simultanous
> snapshots) will take place in the time dimension. You then introduce the "inaccuracy"
> to your dimensions, if any of the planes has changed over time.

Wrong, such rotation is itself a 3D object (x,y,t) just like it's a
time-less geometrical 3D object (x,y,z). There is no inaccuracy, you
just changed the "base" of your vector space.

> > So, this (apparently complex) reasoning brought me to this: I must have
> > a way to "rotate" my browser view so that I grasp the multi-dimensional
> > shape of the requested resource. Most of the time, the "normal" view is
> > the most useful one, but in some situations other views might be even
> > more important.
> 
> The Metadata stream for me has absolutely nothing to do with views, and perhaps
> that's where our imaginations part. I get the feeling that the Metadata streams are
> somewhat an infrastructure for delivering views, in your model. Fine, but then there
> are hardly any difference between the data and metadata stream. Or?
> 
> I had the notion that the metadata stream is to be delivered on the same time plane.
> And having a destination that is or is not equal to the data destination.

Ah, now I see your point!

I agree with you. I came to the conclusion than metaevents are another
dimension of the same view and not another view. This is why I placed
different elements for views and error-handling in the sitemap.

> > For example, semantic crawlers might ask for "semantic view" of a
> > resource, where they obtain the semantic network used in that resource.
> > Or they could ask for the "schema view", or the "hyperlink view" and so
> > on. Humans might ask for "normal" view if they want to simply browse the
> > resource, or "debug view" if they want to know what happened when the
> > resource was created (timing, caching, tracing, logs, etc...), or
> > "content edit view" if they want to change its content or "style edit
> > view" if they want to change the style and so forth.
> 
> But how do you achieve this is real dynamic content?? Due to the time-factor, tracing
> and debugging can not be reproduced, which means it must be stored from the previous
> execution of the normal data stream, which involves an incredible headache of storing
> a lot of irrelevant data.

I know, I know. My question is: how relevant this is? I mean: metaevents
are useful only for pipeline debugging and tracing. So you decide "a
priori" which one of the two dimensions you want to project on your
view, loosing the other one. (well, logging is always saved someplace,
this is just to speed up pipeline debugging).
 
> > > The MetaData event stream will be something similar, but how would that stream
> > > synchronize with the Data event stream? The XSLT processor have no clue when
> > > the Xalan holds SAX events.
> >
> > When the request comes, Cocoon will know what "view" was requested and
> > drive the sitemap accordingly.
> >
> > This basically means: Cocoon switches the servlet output stream to the
> > output of the serializer connected to the meta-event handlers that come
> > from the pipeline.
> >
> >   request -> g -> f -> s -------------->o
> >              |    |    |                 \
> >              |    |    |                  o---> response
> >              v    v    v
> >              +----+----+--> f -> s ---->o
> >
> >                                           ^
> >                                           |
> >                                     view selector
> >
> 
> I understand your approach (although can't see the connection with optical
> modulation), 

The selector is the equivalent of a polarization filter: one
polarization gets thru, the other is blocked.

> but I don't 'feel' it solves the debugging, tracing and so forth.

Why not?
 
> > > >   3) resource (what Niclas proposes)
> > >
> > > Not really what I proposes...
> >
> > No?
> 
> I just indicated one way to do it, not necessarily the best

ok
 
> >
> >
> > > >   4) query (what I proposed)
> > > >
> > > >      path/resource -> normal view
> > > >      path/resource?cocoon-view="tracing" -> tracing view
> > > >
> > > > So the choice is between 3 and 4.
> > >
> > > but again, <map:match pattern="*?cocoon-view=tracing">
> > > is then the same thing??? (presuming now that ? and = is not part of regexp.)
> > > And what you are trying to achieve is syntax reduction.
> >
> > Niclas, the point is that I want to AVOID having to write this into
> > matchers!!!!
> 
> I KNOW, and I don't oppose it. It was a matter of reasoning myself through the pro's
> and con's.

ok
 
> > So, to avoid having to write it, we must make it "implicit" and we must
> > create a design pattern for it. Here we are trying to decide which one
> > is the best design pattern to encode a view into a URI.
> 
> 3 choices;
> a)  Extension to the path.
> b) cocoon-view parameter
> c) any parameter indicated by a configuration property.
> 
> I vote for b.

+1
 
> > > b) Introduction of a 'notion' or 'concept' that otherwise would be
> > > recommendations. By introducing the 'feature' straight into the syntax, one
will
> > > highlight the use.
> >
> > Exactly. I'm very afraid of people "missing" the notion of views
> > entirely. You could use OOP paradigms even in C if you were a good
> > programmer (Apache modules, are, in fact, OOP), but creating a syntax
> > for it forces you to adapt to that way of thinking.... which, sometimes,
> > if the thinking is smart enough, it's not a limitation, but rather a
> > power increase.
> 
> I agree. Although the anarchy is the ultimate level of freedom, people are not wise
> enough to live with rules and guidelines. It is impossible for everyone to realize
> what is best for oneself and for a larger community. We are now touching the core
> difference between humans and other animals. We teach each other, rather than
> everybody do their own research of every aspect of life.

Great vision, it completely resonnates with my feelings.
 
> > > Now, this has led me into another deduction. If the 'view' concept can be
> > > achieved with the existing (interesting concept - "existing" in future tense)
> > > matching proposal, could then this 'extension' be pluggable into the sitemap
> > > specification? (Smells golden hammer, I know).
> >
> > I know, I know.... don't tell me, I went so far down this direction that
> > I had to clean my whiteboard and start over.
> >
> > The "redutio ad unum" design pattern (which I just made up, so be
> > careful) indicates that if you make a layer functionally complete and
> > the ability to extend it, you cover up all space.
> 
> And what's wrong with that? Adding too much complexity?
> 
> > But on the other hand, the "multiple thin layers of glass reflect"
> > design pattern (which I just made up as well), indicate that you might
> > loose functionality if you require many levels of extentions to achieve
> > some very common functionality.
> 
> ok.
> 
> > This is why I do agree that <view> doesn't add any new functionality,
> > but adds a great deal of new "semantic" content to the sitemap and since
> > languages are for humans, not for machines, "semantics" are very
> > important and must not be underestimated.
> 
> Agree wholeheartedly.
> Any HTML/CSS coder, I think, has been through the agony of not using 'semantic'
> capabilities of CSS, such as using the rendering properties (of the initial spec) as
> IDs, instead of using IDs based on content. And that 3 months later, there are
> changes made to the rendering properties, and a lot of work has to be redone instead
> of changing a couple of stylesheets.

I agree, CSS is extremely powerful and sometimes perfect for the job
where XSLT is just too heavy. On the other hand, it's very hard to
understand good patterns of usage and the syntax is so "flat" it doesn't
help you indicating a semantic, a metric to estimate the quality of the
stylesheet in terms of useability, future compatibility and so forth.
 
> > > But assume for a second that each tag in the sitemap is handled by a component
> > > defined in the cocoon.xml (or actually in a separate
> > > sitemap-config) configuration, it would allow for interesting possibilities
of
> > > the future. The drawback?? I don't know at this moment.
> >
> > Sitemap extentions like XSLT-extentions. Hmmmm, smells like FS at this
> > point...
> 
> I know, but I also believe that that the difference in the initial implementation is
> close to none, and hence can be introduced (non-supported at first), for experimental
> use further down the line.

I'd suggest to concentrate on having more feedback from users on what we
agreed so far instead of increasing complexity simply to test the idea
and no apparent reason.
 
> > I will consider the sitemap finished as soon as a good model for views
> > is introduced. I'm working on it right now. As soon as this is done,
> > we'll vote to "finalize" the sitemap WD and we'll move to
> > implementation. (Giacomo is already working on it).
> >
> > When implementation is done, we'll make the first alpha release and
> > people will have real-life feedback. At that time, we'll reconsider the
> > notion of sitemap extentions, but not before.
> >
> > is this plan ok with you people?
> 
> Have anyone ever been opposing implementations??
> Of course not...

Good.

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