On Tuesday 17 November 2009 15:18:13 Xavier Hanin wrote:
> 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).
The last time I worked with Lucene we implemented a such diff and publish
mecanism for Lucene indexes, and it was working quite well. Solr does have a
mecanism for such things too, but the last time I checked it was just relying
on rsync. If somebody is interested I can take some time to explain it here.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
