cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] New Cocoon Site Crawler Environment
Date Thu, 19 Dec 2002 05:17:42 GMT
Nicola Ken Barozzi wrote:
> 
> 
> Berin Loritsch wrote:
> 
>> For instance, part of the issue resides in the fact that any client
>> (i.e. CLI environment or Servlet) can only access one view at a time
>> for any resource.
>>
>> Why not allow a client to access all views to a resource that it
>> needs/wants simultaneously?  That will allow things like the all
>> important profiling information to be appended after HTML pages
>> are rendered.
> 
> 
> I thought of this too. But in practice?...
> 
>> Cocoon is so entrenched in the single path of execution mentality that
>> environments that need the extra complexity can't have it.
>>
>> Each resource should only need to be rendered once, and only
>> once.  Each view to the resource should be accessible by a client.
>>
>> FOr instance, the CLI client wants the Link/Mime-Type information
>> and the content itself.  The Link/Mime-Type information is accessed
>> via the LinkSamplingEnvironment.  In reality, that is a poor name
>> for what you are really wanting to represent.  It should be the
>> LinkSamplingView.  That view caches information that can be incorporated
>> back into the list of links we are resolving.
> 
> 
> Ok, but in practice, how does the client request the view results?
> I kinda like this non-blocking view concept, but fail to see clearly the 
>  practical implementation.

I think this gets back to the whole Multi-Path pipelining thread a while
back (i.e. allowing the multiplexing of a pipeline to serialize results
to the disk while sending the results to the user at the same time.

In the end, I don't think that "Views" as they are defined currently are
what we are really after.  What we want is a way of siphening
information from our pipeline so that we can use it as we see fit.

As such, what we really need is something like a "publish/subscribe"
mechanism similar to the way Avalon Instrument works.  I.e. if we don't
need it, we don't waste precious resources--but if we do need it, then
it is available to us.

I am not sure of the mechanism, but perhaps we can butt our heads
together to come up with the best solution.

---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message