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:
- asks F-R for all possible info (spec file scetions etc)
- extracts more stuff on disk
- reads metadata of all scripts
- orders scripts basing on their dependencies
- executes individual scripts
- 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