cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Sat, 23 Aug 2003 14:13:57 GMT

On Saturday, Aug 23, 2003, at 15:41 Europe/Rome, Gianugo Rabellino 

> Stefano Mazzocchi wrote:
>> On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino 
>> wrote:
>>> Looks like I missed some serious fun during these vacations... time 
>>> to catch up!
>>> Stefano Mazzocchi wrote:
>>>>  Virtual Pipeline Components
>>>>  ---------------------------
>>> Love the idea. Even because it was me suggesting something like that 
>>> a couple of years ago and being blamed of FS... ;-)
>> Really? any pointer? (I'm not being sarcastic, but curious... if I 
>> judged FS something that I later ended up proposing, there is 
>> something wrong in my FS meter ;-)
> Sorry, no pointers, just witnesses if they remind the live discussion 
> who took place one day in Bibop.:-) We were still using the compiled 
> sitemap and I was suggesting how components could have been aggregated 
> (G-T* / T* /T*-S) as "macros" to be unrolled by XSLT. You came up with 
> FS bells and problems with parameter resolving, so the discussion was 
> kinda over.

ahhhhh, yeah, rings a bell... I remember that I thought about 
fragmented resources and it was that that triggered my FS alarm. I 
always knew that views were virtual serializers, but the specific 
semantics was introduced to make it easier to understand (views are 
heard enough to understand already).

But anyway, no excuse, I was probably wrong at that time not to 
consider this further. Or, maybe not: we needed more time to see if it 
really made sense to add that complexity.

> I will be more stubborn next time. ;-)

Please do :-)

>>>>  Pluggable Request Factories
>>>>  ---------------------------
>>> 2. Are you sure that adapting the request is enough?
>> I couldn't come up with anything that required more than that.
>>> I'd say that the different use cases you're pointing out require a 
>>> bit more then just the request object: I'd say that the whole 
>>> environment might need a particular treatment in most cases.
>> Why so, can you elaborate? maybe with a specific example? scenarios 
>> help the design.
> You might need to have access to the response too. In WebDAV world, as 
> an example, you need to set a whole bunch of headers (Allow:, DAV:, 
> MS-Author-Via - yuck - and more), and a DASL component needs to 
> specify the search vocabularies supported. True, you can do it by 
> hand, but it would be much better if such manipulation could be done 
> by a "request-factory".

Damn, great point.

So, back one step: could "adapt-environment" help? or is "environment" 
not good enough for people to understand?

What do others think?

> --

View raw message