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 Wed, 08 Jan 2003 16:01:38 GMT
Nicola Ken Barozzi wrote:

>
> Sylvain Wallez wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Carsten Ziegeler wrote:
>>>
>>>> Sylvain Wallez wrote:
>>>>
>>> [...]
>>>
>>>>> You're totally on track. If you need this action right now, I 
>>>>> would suggest to mimic what's in the DirectoryGenerator, that 
>>>>> makes the assumption that the Source is a file. You can then use 
>>>>> all the facilities given by File.
>>>>>
>>>>
>>>> And we only argue, if this support should belong to the Source 
>>>> interface
>>>> or too an optional extension interface where I always have to do an 
>>>> instanceof to see if the source has childs or not.
>>>>
>>>> :)
>>>
>>>
>>> It's nice when discussions are about where to put something new, 
>>> it's always goodness :-)
>>
>>
>> Welcome to the party, Nicola Ken !
>
>
> :-)
>
>>> MHO: It all depends on what a Source is.
>>>
>>> 1 - If a source is a plug to a URI-based source handler, it should 
>>> have children. 
>>
>>
>> ?? Have you seen children access methods on java.net.URL ??
>
>
> Good point. Actually, it sorta closes the discussion for me :-)
>
>>> 2  - If it's a plug to a resource, it should not.
>>
>>
>> What is a "resource" ?
>
>
> stuff, bytes, bits, whatever ;-)
>
>>> Usually a source is (2), but since we bind the Source to a URI, (1) 
>>> makes more sense. BTW, if (2) is true, specific Sources should 
>>> probably not be the place anyway where to traverse a URI space, or 
>>> else we are in case (1).
>>
>>
>> You lost me ;-)
>
>
> Yeah :-)
>
> Let me try to explain it, it could be fun trying to understand how my 
> fried brain comes up with these sentences:
>
> Usually a source is [intended as something that gives me a resource, 
> that is a data entity], but since we bind the Source to a URI, [that 
> is we get Sources from URIs], [making it hierarchically navigable as a 
> URI space] makes more sense.


IMO, this is wrong, for two reasons :
- an URI space may not be hierarchical. For example, the 'blob' protocol 
isn't hierarchical.
- having a hierarchical URI space doesn't mean that you can navigate 
through this hierarchy : you can only get an URI's parent on some URI , 
but you have no means to get the available children of an URI.

> BTW, if [being simply a handle to a resource] is true, specific 
> [implelentations of] Sources should probably not be the place anyway 
> where to traverse a URI space, or else we are in [the] case [where 
> those Sources are resolvable with URIs, so they should have those 
> methods].


Still didn't got all the essence of it, but what I can say is that 
providing navigation methods makes sense only if the URI space defined 
by a given SourceFactory is hierarchical *and* this hierarchy can be 
traversed.

> If you still don't get it (yes, you should laugh at the complexity of 
> the above) don't worry, *I'm* the mad one ;-)


Aren't we all a little bit mad to send dozen of mails for a bunch of 
methods ;-P

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