On Sun, 10 Feb 2002, Stefano Mazzocchi wrote:

> Vadim Gritsenko wrote:
<snipped/>
> >
> > PS: /dev/null: Currently, aggregator ignores serializer. That's to show
> > that this is the dummy serializer.
>
> Ok, I think you are suggesting something good but I see a few concepts
> that we must think about more:
>
> 1) serializers should have no notion of where their output goes. this is
> a property of the pipeline.

Absolutely!

> 2) there are three types of pipeline:
>
>  - complete: G -> T* -> S
>  - generating: G -> T*
>  - serializing: T* -> S
>
> interesting enough, for the in-out flow, internal-only pipelines are
> 'generating pipelines' and views are 'serializing pipelines'.

And to complete the picture "resources" are complete pipelines.
This helps us finding a better way to structure the sitemap.

 - complete: G -> T* -> S ==> <resource>
 - generating: G -> T*    ==> <source>  (this needs a better name)
 - serializing: T* -> S   ==> <view>

Maybe we should solve the unfinished semantic with the "internal-only"
pipelines first (which you are mentioning as generating pipelines).

And now we could have the <pipeline>s section be the mapping
descriptions from whatever to <resource>s which could pick up <view>s
and/or compose themselfs by means of <source>s.

> So, we already have this semantic, we just have to expand it a little.

That's what I've already mentioned. There is in my opinion no need to
distinguish in from out flow as the mechanism is request -> response
which includes input processing and output processing. For me a general
form of the process is:

  request (1)
  +
  --> analysis of the request (2)
      +
      --> prepare analysis result for processing (3)
          +
          --> process request (4)
              +
              --> prepare processing results for response (5)
                  +
                  --> response (6)

(1) this is what we get from the servlet engine
(2) this is what we do to abstract the environment
(3) this is what the sitemap is doing to match/select/act/generate upon
    request aspects.
(4) this is what generators/transformers might do to satisfy the request
    in a general sense.
(5) this is what transformers do to fit the respose to a certain
    environment
(6) this is what the serializer in question produces

(1),(2) and (3) is what the in flow is about
(4) is the core processing of a request
(5) and (6) is what the out flow is about

You probably see that some parts do overlap (mainly generation and
transformation) but this is because both type of processing can be used
to different kind of actions.

Giacomo



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to