On 08/09/2012 04:47 PM, Stanislav Ochotnicky wrote:
Quoting Mikolaj Izdebski (2012-08-09 15:29:28)
>> Examples are good, especially examples like these. To be fair, I hadn't
>> realized how simple things could be. Have you implemented this using a
>> json plugin handling the communication between "your" plugins and
f-r?!
> Yes, I have implemented this as a single JSON plugin which basically:
> 1) asks F-R for all possible info (spec file scetions etc)
> 2) extracts more stuff on disk
> 3) reads metadata of all scripts
> 4) orders scripts basing on their dependencies
> 5) executes individual scripts
> 6) returns one reply to F-R containing results of all tests
>
> I would love to release this code to the public, but I need to ask my
> employer for consent before doing so.
And I see no reason why we couldn't add this JSON plugin directly into
f-r so that people can write these simple tests in shell (or whatever
decorated madness). We can install it by default into plugin directory,
and
JSONPlugin *almost* works (proved by Mikolaj being able to create
additional checks with it :-) ).
What is missing/wrong:
* Callback nature is sub-optimal. We can extract a lot of stuff and
place it in specific subdirectories in review dir similar to how
Mikolaj's plugins is already doing. We just do it automatically for
everyone (even internal plugins if they are so inclined).
* My original idea was that each group interested in certain package
type would create their "base" check and normal checks would be based
on that. So they would need to develop the JSON handling only once.
I'd even be inclined to package such wrappers directly in f-r to ease
stuff. It was not meant for each reviewer to create their own private
set of checks. And I still don't think we should be aiming there
primarily
So action items:
* Add basic information into ENV variables before calling plugins
Can't
hurt...
* Add support for attachments (maybe I'll just scan contents of
certain
fixed directory and consider each file as an attachment?)
Problem is that json
interface needs to be fixed dirst, certainly doable.
* Create basic plugins in Perl/Ruby/whatever and install them in
system
directories so tests can use them as their base tests in more simple
way without caring about JSON stuff. Plus we'll keep them updated
together with API if needed. We already have basic Perl stuff in the
example, just need to make it more modular so it can be reused.
Which is fine,
only we get the registration data right. We don't want to
change that API from day 1, do we? Also note that running through json
means that we must expand that interface to transfer registtration data
from the simple plugins over Mikolaj's plugin over JSON to f-r (besides
attachments)
Maybe we would be better off rethinking the registration first so we can
make a reasonable attempt on the plugin registration data? And skipping
attachments for simple plugins until we have reimplemented MIkolaj's
plugin in python? instead of wasting time on the json interface?
* Include Mikolaj's plugin so people can create *really* simple
stuff
with small shell scripts
Or does it sound really that bad?
No, not that bad. The yat tool thing can be posponed, and evolve over
time. But I would sure like to get things right first: registration, API...
--alec