Re: Announcing quic-explorer.net: A Resource for QUIC Library Comparison and Selection

[Marcel Kempf <[e-mail]>]

I think that the ideas can also be combined well. I really like the idea 
of the pull model, the data could then be automatically rendered to 
Markdown and put into the QUIC WG Wiki. This could happen for example 
every week by a Github Action.

Before I built QUIC Explorer, I also had a big Markdown file with 
information about congestion control of QUIC implementations. As Lucas 
already mentioned, Markdown is not structured and cannot be properly 
filtered, processed or machine-read. The option of storing the data in 
JSON and rendering it flexibly to a static website (or Markdown) quickly 
seemed more suitable to me. I just pushed a short 30-line proof-of-work 
script here 
<https://github.com/MPK1/quic-explorer/blob/main/cli/create_markdown.py> 
that produces Markdown that looks like this 
<https://gist.github.com/MPK1/cffb5c6a56a75e3d604a8835e2d55c2b>.

I also just created a json file with some structure that could be 
improved and used for a pull model 
(https://gist.github.com/MPK1/8765fc25bb98d437491ebcc6c55d09a9)

Marcel

Am 20.07.24 um 01:14 schrieb Lucas Pardue:

>
> On Fri, Jul 19, 2024, at 06:44, Christian Huitema wrote:
>>
>> On 7/19/2024 12:42 AM, Marcel Kempf wrote:
>> > Hi Lucas,
>> >
>> > This is also the way this projected started: People asked me if
>> > something like it exists and after saying no again and again, I 
>> realized
>> > the need for it, especially as the QUIC Implementations wiki page on
>> > Github (https://github.com/quicwg/base-drafts/wiki/Implementations) is
>> > also quite outdated and not really extensible.
>> >
>> > Considering the pull model: I have not yet thought about that, but
>> > that's a great idea, thank you! I already have some nice ideas what
>> > could be possible, so I opened an issue
>> > (https://github.com/MPK1/quic-explorer/issues/5) and will add some
>> > proposals soon.
>>
>> If we have a defined format, cannot we use it in the QUIC WG Wiki?
>
> There's options for sure, and I wouldn't want to rule any out at such 
> an early stage.
>
> Speaking of only my own experiences. The QUIC wiki was vandalised at 
> some point in the recent past and I locked down permissions. I can't 
> recall how restrictive those are. Possibly too restrictive to let the 
> ecosystem continue to bloom. Furthermore, having to use markdown 
> doesn't seem particularly structured to me. JSON in markdown sounds yucky.
>
> The model I personally like is for projects to define their own source 
> of truth that is owned by them and pulled from. This seems to work 
> pretty well for the interop runner tests.
>
> As another source of inspiration, see 
> https://github.com/mdn/browser-compat-data, which contains browser 
> oriented machine readable data that is used by a variety of tools such 
> as MDN, caniuse and more.
>
> Cheers
> Lucas
>> -- Christian Huitema
>>