[Tools-discuss] Re: PDF [Re: Tools team meeting tomorrow 9 July 2024 1800 UTC]

[Robert Sparks <[e-mail]>]

On 7/8/24 10:16 PM, Carsten Bormann wrote:
> Hi Robert,
>
> Thank you for responding to this.
>
> On 8. Jul 2024, at 23:29, Robert Sparks <[e-mail]> wrote:
>>
>> On 7/8/24 1:34 PM, Carsten Bormann wrote:
>>> On 8. Jul 2024, at 20:27, Robert Sparks <[e-mail]> wrote:
>>>> The agenda and the beginnings of notes for the meeting is available at https://notes.ietf.org/tools-team-20240709. Details will continue to be added up to and during the meeting.
>>> This discusses expensive resources (“endpoints”) for building PDF forms of documents.
>>>
>>> Could we maybe stop pdfizing things in weird ways and simply build the correct PDF form on I-D submission?
>>> The current state is just such a waste of time.
>> This glosses over a lot, so lets dig a little:
>>
>> - by "correct PDF form" I assume you mean what xml2rfc would produce given xml input.
> Yes.
> Something good enough to judge what the RFC editor will ultimately publish.
>
>> What about drafts that are still being submitted as text only
> I personally don’t care.  OK, you have to do *something*.
>
>> - do we stop providing any pdf form of those? What about drafts and RFCs from more than 5 years ago?
> So do something.  PDF-printing the .TXT seems to have worked so far.
>
>> - The expensive part is running the pdf creating software (currently weasyprint) and moving that expense to draft posting time vs the first time someone accesses the pdf document just moves the expense around.
> The expense is trivial (*).  The difference is whether I have to wait while the data is generated on demand or they can be provided immediately (or already is on my laptop via rsync).  I sure value my time more than that trivial expense.
>
>> It might even make the total expense higher if no-one every asks for the pdf of a particular version of a draft.
> That is true, but probably not relevant (*).
>
>> - One sharp edge is running the pdf creating software over provided svg (even with our badly constructed restrictions on the SVG). We know of extant submissions that cause the pdf generation call to fail to return.
> I can imagine that.  No soup for these drafts then (fall back to PDF-printing the TXT).
>
> Grüße, Carsten
>
> (*) conservative estimate: 2000 active I-Ds, each submitted 10 times per year, at 20 s of CPU per ingestion.
> That is about 111 CPU hours per year, or < $10/yr on AWS at retail prices?
> You writing your response already cost more...

And then the cost of maintaining the store - _updating_ the store when 
something fundamental changes that demands that we rerender the pdf (the 
basis becomes _all versions of all drafts in the archive_ at that 
point), and the time it takes to move the collective set of bits 
repeatedly when bots scrape them and individuals/bots do new blind 
full-rsyncs. All that can be optimized downwards and towards the edge, 
but dismissing this as a conversation about <$10/yr is incorrect.

Fwiw, the _current_ implementation (in place for many years) computes 
these on demand _in the HTTP transaction that asks for them_ if they 
haven't been computed already, and stores them in a disk-backed cache. 
These builds and the time used to shovel the results compete with the 
other things users are asking the datatracker to do and are a major part 
of slowness when the datatracker is slow (adding more to the collective 
expense of making/keeping them as we make all of our contributors wait 
to do other work. Yes, that can (and must) be redesigned to make better 
use of modern web technologies, and my initial question is about whether 
we invest in a redesign that moves this to places that help more people 
more of the time, or if we are far enough along that people can build 
these locally, closer to the origin.

Your argument to keep them is to promote reviewing all the formats as if 
they are going to become RFCs (at least for xml source). That would be 
better done _before_ submission wouldn't it?


>
> -----------------------------------------------
> Tools-discuss mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> https://mailarchive.ietf.org/arch/browse/tools-discuss/