Hi Jörn,
thanks for your comments!
Jörn Nettingsmeier schrieb:
[...]
>> A possible solution would be to pass the ID of the current publication
>> to the fallback URL, for instance
>>
>> fallback://{pubId}:xslt/foo2bar.xsl
>>
>> This would also fix the template-fallback problem described in
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=40564.
>
> hmmm. i think this is quite ugly. why mess up the user-visible part of
> the fallback api with redundant information?
At least for template-fallback://, the information is not redundant
(see bug 40564).
> can't we rather attach the
> publication information to the session as an intermediate measure?
The request URI is sufficient, attaching the information to the session
doesnt help because SourceFactory.getSource() doesn't get a parameter
which contains a reference to the request or session. We could take a
closer look at the SitemapSourceFactory though, which certainly has to
deal with similar issues and is ThreadSafe.
> i'd hate to clutter the fallback semantics with performance hacks that
> work around avalon problems, especially since cocoon is moving to
> spring, where such things are a lot cheaper i'm told.
OK, that's a good point.
>> Unfortunately we can't make this optional, because the
>> FallbackSourceFactory is either ThreadSafe or not. But in a first step
>> we could introduce an additional protocol, e.g. pubfallback://. I
>> implemented this as a prototype in my sandbox, and it seems to work
>> fine. We can also do this if we defer the implementation until after the
>> release and recommend to change the URLs for better performance.
>
> i'm not happy with this. fallback:// is part of our user interface imho,
> and as it is now, it's great and fun to use. pubfallback:// sounds
> contradictory to me.
>
>> 2. Checking the existence of the sources is expensive.
>>
>> For each fallback source resolving, we check the existence in each
>> publication of the hierarchy, up to the core. This is of course quite
>> expensive. We could keep this for the "development" mode, and introduce
>> a "production" mode which caches all locations until the cache is
>> cleared manually.
>
> isn't fallback cacheable?
Even if the source is cached, the validity check is extremely expensive
because it has to look up each version of the source in the publication
hierarchy (a file might have been created or removed from the hierarchy).
> i.e., if a source is requested twice,
> shouldn't it come from the cache the second time? so how would your
> additional cache make a difference?
I wasn't focusing on an additional cache, the existing cache would be
sufficient. What I meant is that we could disable the source lookup
described above in production.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
