RE: [Tm4j-developers] Index interface proposal checked in

[Kal A. <ka...@te...>]

Oops - forgot to cc the list on this one.

>Date: Wed, 27 Feb 2002 09:28:10 +0000
>To: "Florian G. Haas" <f.g...@gm...>
>From: Kal Ahmed <ka...@te...>
>Subject: RE: [Tm4j-developers] Index interface proposal checked in
>
>At 00:25 27/02/2002 +0100, you wrote:
>>Hello!
>>
>>I must admit I'm certainly no expert at this, but what you are saying about
>>the general purpose of these indexing mechanisms makes sense to me. Having
>>had a look at the interface definitions themselves, I have a couple of
>>questions:
>>
>>* What's the difference between an "open" and an "initialized" index? In
>>other words, how would IndexProvider.getIndex().isOpen() be different from
>>IndexProvider.getIndexMeta().isInitialised()? And how would that, in turn,
>>differ from IndexManager.getIndexMetaData().isInitialised()?
>
>I think that is an inconsistency that needs to be removed. The close() 
>method was actually added after I had sketched out the design, so I think 
>that changing "initialise" to "open" in most places would make sense.
>
>The difference between IndexProvider and IndexManager is that a 
>IndexProvider is essentially an SPI (service provider interface) that 
>needs to be implemented by developers wishing to add their own indexes to 
>a TM4J application. IndexManager is an API for developers wishing to use 
>indexes through TM4J. So there should be no way for a "user" of the 
>IndexManager interface to ever get hold of a handle to the IndexProvider - 
>hence the extra layers.
>
>I think that the IndexMeta.isInitialised should probably be removed - that 
>is more state information than meta information about the index. I think 
>that the state information should be accessible through the Index object 
>itself.
>
>I'll update the interfaces accordingly.
>
>>* What would be an "explicit runtime initialisation" as mentioned in the
>>documentation for IndexManager?
>
>My thought was that some of these indexes might be quite heavy in terms of 
>local resources used and so you wouldn't necessarily want them open as 
>soon as the IndexProvider is loaded (seeing as an IndexProvider might be 
>providing a set of indexes). So I originally intended explicit runtime 
>initilisation to be the act of calling IndexProvider.getIndex(), but I 
>think in retrospect that adding Index.open() would make sense and would 
>put the explicit initialisation in the right place.
>
>Cheers,
>
>Kal