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:// slt/f
oo2bar.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: dev-unsubscribe lenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|
