Jacek,

>   > I just got sick of re-doing the plumbing every time
>   > a new feature needed some statistic or characteristic
>   > that was already derived but sent directly to where
>   > it used to be needed.
>
> I think that is an indication things are not
> compartmentalized correctly yet :)
True, but my point is that we don't really know what a correct 
compartmentalization looks like, and I'm not sure we will, until we're 
feature-complete for query syntax, schema, partitioning, and execution. 
Thanks to xrootd, there are no dependencies on physical chunk 
distribution. I don't mind putting things into bundles as you've done so 
far (but I think containment rather than multiple-inheritance is the 
right approach), but I feel strongly that each plugin should have the 
plumbing to access everything (ok to restrict access through 
friend-declarations, though). This is what allows (in theory) adding 
features by adding plugins, rather than touching all the other parts 
that might care and adding plumbing to connect all of them.

>   > If you can find portions that are really
>> only used by one plugin, we can move it to that plugin
> It is the case for _restrictors, it could easily go into
> the restrictorPlugin, but... testQueryAnalysis is checking
> few things relates to _restrictors, so, how would you
> implement that? We could iterate through the list of plugins
> that QuerySession keeps, find the restrictorPlugin and
> do the calls testQueryAnalysis needs (what is the number
> of restrictors, give me the first restrictor). Is it too ugly?
I think it's too ugly. I could conceive of other plugins needing to know 
about those restrictors, and accessing the plugin itself seems like the 
wrong approach. But maybe we always want a name-based lookup for 
plugins, available only for test programs. And maybe we'll decide to put 
all restrictor-related code in that plugin. I'm not ready to say. I do 
think the open-access plugin approach with its centralized data exchange 
has made query analysis code much easier to write--the data is always in 
one place and you don't have to worry about the other analysis (as 
much). That said, the division of logic in the current plugins may not 
be correct.

-Daniel

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1