[
https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin updated IVY-399:
-----------------------------
Description:
Creating an issue at Xaviers request for improving the approach to cache
management
On 1/29/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
Supporting this kind of graph
could be interesting, and what makes it difficult for Ivy is that Ivy
heavily relies on its cache mechanism, which makes it impossible to do
what you want (i.e. never put anything from your local repository to
the cache).
This would be a very powerful feature to add. In 2.0, is there any reason for
the cache to have to be so baked into everything? In otherwords, why not
implement every resolver and all of the internal management w/ no caching what
so ever baked in anywhere? Instead all caching is done in a decorator fashion
by wrapping a caching resolver around any other resolver? In otherwords, the
core of Ivy only knows about resolvers, no concept of cache exists in the heart
of Ivy.
It seems to me this would be much more flexible, and it would still be very
possible to provide the syntactic sugar to make it very simple and even
seemless to configure these wrappers by default. At the same time, people who
will use the flexibility have the power to set up chains that might go
something like.
(logical chain)
localresolver
cacheresolver
httpresolver url="..."
cacheresolver
httpresolver url="..."
There is no longer any need to have things like useLocal flags. Its already
expressed that the local resolver is not cached because its just not wrapped in
a caching resolver.
I think this idiom should be applied to both artifact and metadata resolution.
One cool thing about this, is that in this way, since all caching is simply a
type of resolver we'd provide people who don't like the particular method we
use to perform caching in the resolver we provide are free to provide their
own. This would address lots of the issues that have been raised about caching,
consistency, doing anything remotely fancy with local resolvers - right now its
very hard to address any of that because caching is not very plugable as it
stands.
I think the only drawback is that it seems like its harder to configure out of
the box because most people by default would want to wrap every resolver with a
cacheresolver - but like I said, this is easily solvable by providing some
simple syntactic sugar. For instance the simplehttpresolver might be the name
of an undecorated resolver for power users, and the things named httpresolver
would simple be an alias for the cacheresolver wrapped around the
simplehttpresolver (or subclass, whatever is the most sensible choice)
was:
Creating an issue at Xaviers request for improving the approach to cache
management in Ivy 2.0
On 1/29/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
Supporting this kind of graph
could be interesting, and what makes it difficult for Ivy is that Ivy
heavily relies on its cache mechanism, which makes it impossible to do
what you want (i.e. never put anything from your local repository to
the cache).
This would be a very powerful feature to add. In 2.0, is there any reason for
the cache to have to be so baked into everything? In otherwords, why not
implement every resolver and all of the internal management w/ no caching what
so ever baked in anywhere? Instead all caching is done in a decorator fashion
by wrapping a caching resolver around any other resolver? In otherwords, the
core of Ivy only knows about resolvers, no concept of cache exists in the heart
of Ivy.
It seems to me this would be much more flexible, and it would still be very
possible to provide the syntactic sugar to make it very simple and even
seemless to configure these wrappers by default. At the same time, people who
will use the flexibility have the power to set up chains that might go
something like.
(logical chain)
localresolver
cacheresolver
httpresolver url="..."
cacheresolver
httpresolver url="..."
There is no longer any need to have things like useLocal flags. Its already
expressed that the local resolver is not cached because its just not wrapped in
a caching resolver.
I think this idiom should be applied to both artifact and metadata resolution.
One cool thing about this, is that in this way, since all caching is simply a
type of resolver we'd provide people who don't like the particular method we
use to perform caching in the resolver we provide are free to provide their
own. This would address lots of the issues that have been raised about caching,
consistency, doing anything remotely fancy with local resolvers - right now its
very hard to address any of that because caching is not very plugable as it
stands.
I think the only drawback is that it seems like its harder to configure out of
the box because most people by default would want to wrap every resolver with a
cacheresolver - but like I said, this is easily solvable by providing some
simple syntactic sugar. For instance the simplehttpresolver might be the name
of an undecorated resolver for power users, and the things named httpresolver
would simple be an alias for the cacheresolver wrapped around the
simplehttpresolver (or subclass, whatever is the most sensible choice)
Summary: Flexible Cache Management (was: Caching in 2.0)
I update the title to reflect more the intent than the target version, which
could change if we maintain backward compatibility.
> Flexible Cache Management
> -------------------------
>
> Key: IVY-399
> URL: https://issues.apache.org/jira/browse/IVY-399
> Project: Ivy
> Issue Type: Improvement
> Environment: ALL
> Reporter: Eric Crahen
>
> Creating an issue at Xaviers request for improving the approach to cache
> management
> On 1/29/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> Supporting this kind of graph
> could be interesting, and what makes it difficult for Ivy is that Ivy
> heavily relies on its cache mechanism, which makes it impossible to do
> what you want (i.e. never put anything from your local repository to
> the cache).
> This would be a very powerful feature to add. In 2.0, is there any reason for
> the cache to have to be so baked into everything? In otherwords, why not
> implement every resolver and all of the internal management w/ no caching
> what so ever baked in anywhere? Instead all caching is done in a decorator
> fashion by wrapping a caching resolver around any other resolver? In
> otherwords, the core of Ivy only knows about resolvers, no concept of cache
> exists in the heart of Ivy.
> It seems to me this would be much more flexible, and it would still be very
> possible to provide the syntactic sugar to make it very simple and even
> seemless to configure these wrappers by default. At the same time, people who
> will use the flexibility have the power to set up chains that might go
> something like.
> (logical chain)
> localresolver
> cacheresolver
> httpresolver url="..."
> cacheresolver
> httpresolver url="..."
> There is no longer any need to have things like useLocal flags. Its already
> expressed that the local resolver is not cached because its just not wrapped
> in a caching resolver.
> I think this idiom should be applied to both artifact and metadata resolution.
> One cool thing about this, is that in this way, since all caching is simply a
> type of resolver we'd provide people who don't like the particular method we
> use to perform caching in the resolver we provide are free to provide their
> own. This would address lots of the issues that have been raised about
> caching, consistency, doing anything remotely fancy with local resolvers -
> right now its very hard to address any of that because caching is not very
> plugable as it stands.
> I think the only drawback is that it seems like its harder to configure out
> of the box because most people by default would want to wrap every resolver
> with a cacheresolver - but like I said, this is easily solvable by providing
> some simple syntactic sugar. For instance the simplehttpresolver might be the
> name of an undecorated resolver for power users, and the things named
> httpresolver would simple be an alias for the cacheresolver wrapped around
> the simplehttpresolver (or subclass, whatever is the most sensible choice)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
