Perl's not the only TAP source

[Steve Purkis]

On 20 Jun 2009, at 14:21, Andy Armstrong wrote:

> On 20 Jun 2009, at 14:14, Steve Purkis wrote:
>> So the todo list:
>>
>> 1. Get people to agree whether or not we need a generic plugin
>> interface.
>> As far as I can tell, there are 2 options:
>> * source & formatter plugins only (ie: source API stays the same)
>> * generic plugins (API not defined yet)
>
> I'm not what else there is to make pluggable apart from formatting and
> source handlers - but I'm open to suggestions.

Me neither :).

Assuming we settle on this, the next question is: should we allow the  
user to supply config and auto-load formatters as we do with sources?


>> 2. Figure out what to do with TAP::Parser::Iterators.
>> I'm still not convinced we need a separate class of iterators for
>> the parser to use.  Source classes could be iterators too, and that
>> would remove the need for the IteratorFactory class, which basically
>> just makes decisions the Sources could make themselves.
>
> Yeah, I think that's right; a source should be an iterator.
>
>> Of course, in your examples you seem happy to delegate the running
>> commands to the iterator classes.  So maybe they should stay after
>> all?  Or maybe we can just get rid of the 'Factory' class, and let
>> the source classes use the iterators directly?  I know I introduced
>> it, and for valid reasons at the time.  I just feel it over-
>> complicates things now.
>>
>> Andy/Eric: It'd be good to have your thoughts here.
>
> Simplify! Unless we can come up with a good reason why the iterators
> are distinct from sources they should go.

Well, at the very least the IteratorFactory should go.

Thinking about it a bit more, one reason I can think of why Iterators  
themselves shouldn't go is if it makes writing a Source plugin any  
more difficult.  Say we put all the complexity of the Process iterator  
into the Executable source, won't plugin-authors that are using roles  
would either be forced to sub-class, or re-implement that logic in  
some way?  Or am I missing something?


>> Now the bad news as for when I'll be free...  I've got an exam to
>> prep for in a week and a half, so hopefully after that.
>
> Hmm. I wonder if I shouldn't have merged sourcedetector into master
> then. I'd like to be able to make a release of 3.18 if the need
> arises. Thoughts?

Well, it is releasable as it stands.  The main thing is to avoid  
setting the new API in stone, which we can easily do in the pod.  I  
know I've started on that ('sources' in TAP::Harness & TAP::Parser).   
I've just noticed the TAP::Parser docs need updating (grep for TODO),  
that's probably the only thing that would need to be updated for a  
release.

Alternatively, it can always be un-merged until we settle on the  
interface & implementation.

Finally, others can always help take this forward :).

-Steve
(who really should be studying :)