cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Defining Source Interfaces
Date Mon, 06 Jan 2003 18:12:42 GMT
Stephan Michels wrote:

>On Mon, 6 Jan 2003, Sylvain Wallez wrote:
>
>>Stephan Michels wrote:
>>    
>>
>>>>>   /** Return the parent source. Returns null if the source hasn't a
>>>>>parent. */
>>>>>   public Source getParentSource() throws ProcessingException,
>>>>>IOException;
>>>>>}
>>>>>
>>>I don't return Sources, because Sources can be Components, which
>>>must be resolved/released by the SourceResolver.
>>>So I think returning the URI instead of the Sources is a must-have.
>>>
>>I disagree : the SourceResolver is used to get a Source from its URL,
>>but a Source is not a component : the component is the SourceFactory
>>that creates Source instances. A source itself is not managed by a
>>ServiceManager.
>>    
>>
>
>But can managed by the SourceResolver.
>

Can you elaborate ? I was meaning that a source has no defined 
lifecycle. Even the release that is managed by the factory and not the 
source itself.

>>Also, having to hop through the SourceResolver to get parents or
>>children of a Source *really hits performance*, as each call to
>>resolve() looks up/releases the factory, asks it to create the source,
>>etc, etc.
>>    
>>
>
>But if the creation of the Sources is expensive, is is easier to create
>a SourceResolver, which holds a pool of the sources.
>  
>

Can you elaborate again ? You can only manage a pool of equivalent 
objects that can be reused. Sources don't fall in this category, as a 
Source is intimately tied to its URI and the range of URIs is infinite.

Furthermore, managing a pool would not be very different 
performance-wise than going through the standard resolution mechanism.

>>Looking at all traversable sources I know of (Slide source and my
>>yet-unpublished CVSSource and TraversableFileSource), getting the
>>children or parents Source objects is really trivial and lightweight
>>compared to the processing required if we go through the SourceResolver.
>>
>>Furthermore, I'm really wondering now if we need to release() a Source,
>>as I can't find any implementation that actually does something of it.
>>
>>And I don't think an implementation will ever use it : the point where
>>something has to be released in Sources is related to stream methods
>>(look at BlobSource.getInputStream()). Also, these methods can be called
>>several times during the lifetime of the Source object, and their result
>>can last longer than the Source object's lifetime (look at
>>XSLTProcessorImpl.resolve()).
>>
>>And releasing a Source involves once more a look up/release of the
>>SourceFactory to actually do nothing...
>>
>>So, considering that the SourceResolver is one of the most used
>>components, removing release() from this interface may lead to a
>>significant performance increase.
>>    
>>
>
>That can be, but a resolve/release has much cleaner lifecycle. For
>example, if the Source lookup for a component using the componentmanager,
>which got the Source by the Composable contract, the component must
>release the component, if the Source were disposed.
>  
>

Sorry, I don't understand what you mean above :-/

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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


Mime
View raw message