2009/11/16 Jon Schneider <jkschnei...@gmail.com>
> On Sat, Nov 14, 2009 at 9:42 AM, Xavier Hanin <xavier.ha...@gmail.com
> >wrote:
>
> > One thing I'm not sure to fully understand: it seems that you plan to
> store
> > the index on the client (say the developer's box), according to your
> > example
> > with dir="${ivy.settings.dir}/index". But it also seems like every client
> > will have the responsibility to maintain the index, is that right?
> Sound's
> > strange, there's probably something I miss?
> >
>
> As a best practice recommendation, I would suggest that the index be stored
> on the same box as the repository (of course, I think the index task and
> the
> proxying resolver should allow for the index to be stored anywhere you
> choose).
When you say "anywhere you choose", is it limited to a location on the
filesystem? Or do you intend to make use of ivy repositories access/publish
mechanism to store the index remotely? With filesystem only the usage sounds
rather limited. With ivy repository mechanism you can store your index on
the same kind of store as where you put your modules, but you will need a
more advanced syntax to configure it, and more advanced implementation.
> I do not see any reason for there to be more than one index per
> repository.
>
> This single index should be as close to representative of the real-time
> state of the repository as possible. In the case where repository
> artifacts
> are added mainly through publish/deliver/install and these tasks are routed
> through the indexing proxy, the index will always match the real-time state
> of the repository. In the case where repository artifacts are added
> manually by a repository administrator, the index will lack the types
> defined in these artifacts until the administrator runs the index task.
>
> Thus, the responsibility for maintaining the index belongs with the some
> combination of the proxying resolver and the index task, their precise
> relationship being defined by the use case.
>
So you will have to deal with index locking during updates, which may become
a contention point, and be difficult to implement if you want to allow using
any repo to store the index.
>
> All clients would then read from the same index. The Quick Search feature
> only reads the index, it does not modify it.
>
If the index grows, accessing the index from a remote box may become long.
If you think big, you will have to find a way to transfer index updates to
the clients which is optimizing the network, such as transferring diffs or
something similar. But this becomes difficult to implement, unless you want
to rely on existing technology for that (such as a SCM).
So IMO for this to be useful for most situations it needs to designed
carefully.
Xavier
--
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/
