RunnerSyntax -> QuerySyntax

[Fabrizio Montesi]

On Tuesday 07 April 2009 08:34:05 Aaron J. Seigo wrote:
> > > and i realized at that point that RunnerSyntax is probably not overly
> > > specific to runners... but rather to documenting what you can do with
> > > queries.
> > >
> > > it occurred to me that perhaps i should rename RunnerSyntax to
> > > QuerySyntax and look into using it for DataEngines and Services.
> > > thoughts?
> >
> > The rename looks sensible in this case, but again we should also think
> > about the implementation. Sure such a thing for engines is surely needed
> > also (hint,hint) in preparation for Plasmate. (Having a very simple and
> > on the go documentation for engines would be a big plus for our Plasmate
> > users)
>
> that's exactly what i was thinking of.
>
> when we put plasmadataengine together, it became evident that a lot of
> engines require one to know how to use them. what can you ask them for, for
> instance? so some sort of runtime documentation would be great. :)
>
> i'm still not sure how i want to expose it .. it might be cool, for
> instance, to have it as a "special" source you can request, e.g.
> DataEngineSyntax. but it might also be more straightforward to just do it
> exactly like it's done in AbstractRunner with a syntaxes() method.
>
> anyways ... any objections before i got and make the name change in
> preparation for this path?

Stream of consciousness follows, but i didn't understand very well how a 
simple syntax may apply to a DataEngine... so please check if Plasma wisdom 
applies. ;)

Can we extend all this reasoning to a DataEngine registry that contains 
information about other DataEngines/Services? That would be nice because we 
could reuse it in a networked Plasma.
Moreover (as you probably already thought with your DataEngineSyntax idea) 
this would isolate all the metadata thing in a single DataEngine. This could 
be good, because metadata about a data source may be way more complex than 
metadata about a Runner and such a solution would leave room to future 
extension to the metadata format.
The bad side of this solution would be that it's more complex than simply 
adding a method to, say, DataEngine (e.g. syntaxes()), and that we would need 
some way to equip DataEngines and Services with metadata in some way (because 
putting it directly inside the registry DataEngine would break isolation).