Request to make irreversible pd4ml methods reversible

#26862

Hey PD4ML,
Would it be possible to make the the irreversible methods on the PD4ML class reversible? For example, the following methods all cannot be undone:
disableHyperlinks()
enableDebugInfo()
fitPageVertically()
adjustHtmlWidth()

Many times, I use one PD4ML instance to render several documents, and these are fields that i would like to switch on and off during use. Instead, I have to completely re-create a new PD4ML instance every time I want to undo one of these changes. Would this be easy to make happen in an upcoming release?

#29377

We recommend to create a new instance of PD4ML class for each conversion request. A class creation overhead can be ignored (comparing to massive resource consuming by HTML rendering). Usually that helps to prevent many difficult-to-detect problems like simultaneous access to the same PD4ML instance from multiple threads.

With a new instance there is no need to perform reverse API calls – you just do not trigger methods you do not need.

But you are right – from some point of view the actual API is not fully consistent. We plan to review it in new PD4ML generation (as well as to sacrifice some legacy features).

#29378

Any decent Java developer knows that using thread-unsafe methods on an instance from multiple threads will lead to inconsistent behavior. In this case, it makes sense to instantiate a new instance, and I think developers know this already. It just comes with the territory of parallel programming.

However, why would you intentionally design the API around the parallel use case when the serial use case is just as valid and probably used just as often? For instance, if the developer wants to set up a PD4ML instance with the same options and footers and headers for a large batch of documents that they plan to render in serial, why would you have them instantiate a new PD4ML object and set these options every time? That’s unnecessary and time consuming.

I appreciate that you’re reviewing your API and making it consistent. I’m just requesting that the API be considered from several use cases. Not just the most complicated one.

#29379

By an HTML rendering PD4ML instantiates tons of objects to represent even a minimalistic HTML document. Each tag or a standalone whitespace requires a creation of a couple of objects: a tag and its properties table etc.

A reusing of PD4ML instance may save a few nanoseconds, comparing to hundreds of milliseconds needed for an entire conversion procedure. If you find that still worthwhile, we’ll make the corresponding properties “public” in the next beta release, to let you reset them if needed. (We are conservative with any legacy API changes and would prefer to keep them as it is now, until a new generation of PD4ML came).

Unfortunately in our business we cannot rely on “decent developers” use our tools. From about 10 years of PD4ML support practice we learned a lot of really “creative” ways one can misuse the library (and programming paradigms in general). So simple rules, like “do not reuse an instance”, works always; a dispatch to a “best practice” may lead to new troubles.

[Author]

Posts