Re: Enfiladealigner (was: Re: [Gzz] Ids)

[Benja Fallenstein]

Tuomas Lukka wrote:

> > > But either way, aligner represents a complicated functionality that has 
> > > a lot of *policy* embedded into it as assumptions and should not be set
> > > on a space-wide way. 
> > >
> > > What you want to happen depends on where you are.
> > >
> > >      
> > Yes, I know... it's a two-dimensional problem: You may want different 
> > implementations at different times, but implementations also depend on 
> > the implementation of the space.
> >
> > Maybe have a factory of strategies connected with the space, something a 
> > bit like Sun's security providers? Hmmm...
> >    
>
> Not necessary: if it's like you said above, the text class can *check*
> whether there's a VStreamTexter or not. Checking the type is a fast operation,
> so I think this would be ok.
But if it's not a VStreamTexter, what do we do? For example, if it's a 
cell texter handling included objects through containment, as you 
proposed (cannot be represented in an Enfilade1D).

> > Ok. But StringSearcher does have a similar problem as above the cell 
> > texter must know the StringSearcher, yet we'd like to have different 
> > strategies at our disposal. Can we solve this somehow? Recreating the 
> > table each time we enter another character of the search string is 
> > certainly not an option.
> >    
>
> I don't think it's really a problem: database indices work exactly in 
> this way: you can attach the indices anywhere and they get updated
> either when you use them or when changes occur. All that needs to happen
> is for the stringsearcher to get the updates e.g. through the deltaspace.
>  
Of course. The question is how? StringSearchers don't want to know about 
the deltaspace (they're completely independent of the gzz package) and 
besides, the deltaspace is not in use yet. (Is someone going to bring it 
into use?)

-b.