Re: [Tools-arch] Recommendation 10: One-stop shop tool

I understand the concerns but this came through from multiple respondents who consider our DIY, multi-tool approach to be a big barrier to participation so I would really like us to think through the details before coming to a view. 

For example, I can see how we might achieve this using Atom as a base editor as that has XML, XSLT, schema validation and version control already handled by existing plugins and us writing new plugins for 
- data tracker submission/retrieval
- YANG validators
- conversion to TXT, PDF etc
- boilerplate insertion/update
- and so on

If those plugins are actually just lightweight clients of central APIs that deliver the heavy lifting then it becomes even easier. 

Jay

-- 
Jay Daley
IETF Executive Director

> On 9/04/2021, at 4:40 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> This seems to go against the 'small pieces loosely joined' philosophy of tool-making seen in our community (and broader technical communities, such as Unix).
> 
> It also seems to reinforce the centrality of the tools team -- i.e., if I want to get any leverage in the ecosystem (e.g., with a format validator), I have to write a plugin for the tools team, rather than writing something that merely operates on a format (see eg <https://github.com/mnot/rfc-http-validate>). I don't think that's something we should be doing.
> 
> Finally, writing a multi-OS GUI tool to 'do everything' is NOT a small undertaking. I'd like to see a trend towards smaller, more controlled tools, not bigger ones.
> 
> Cheers,
> 
> 
>> On 9 Apr 2021, at 11:13 am, Jay Daley <jay@ietf.org> wrote:
>> 
>> =  Recommendation
>> 
>> Recommendation 10:  A ‘one-stop shop’ tool should be investigated. 
>> 
>> =  Commentary
>> 
>> By a ‘one-stop shop’ tool we meant a tool with the following characteristics:
>> 
>>    • GUI based, single tool that works on most OSs and allows an author to do everything they need on I-D drafting/processing in that one place. 
>> 
>>    • WYSIWYG interface that hides the complexity of the underlying XML, in much the same way that any modern word processor does.  (This does not have to be the only interface as some may want to work on the underlying XML).
>> 
>>    • Has a plugin mechanism so that any I-D processing tools can be added in for direct invocation.
>> 
>>    • Interacts with the Datatracker for submission and retrieval of I-Ds and associated metadata.
>> 
>>    • Interacts with ‘official’ IETF GitHub repositories, including for the processing of issues, pull requests and other collaboration features. (Also see recommendation 13 below)
>> 
>>    • Directly supports the AUTH48 process.
>> 
>> In order to produce such a tool, the various I-D processing tools would need to be refactored to work as plugins, going back to the concept under recommendation 6 with them all implemented as APIs, supporting any variety of client.
>> 
>> Is this something the TAS Team would like to start the ball rolling on recognising that there would be lots of community discussion required?
>> 
>> 
>> 
>> -- 
>> Jay Daley
>> IETF Executive Director
>> jay@ietf.org
>> 
>> -- 
>> Tools-arch mailing list
>> Tools-arch@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-arch
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> -- 
> Tools-arch mailing list
> Tools-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-arch