 |
 |
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