[vlc-devel] [PATCH] stream_ReadLine: increase line length limit

[Pierre Ynard]

> A common data structure API can probably expose all parsed data
> formats (tree, nodes, key val properties), callbacks based (because
> of HTML unpaired tags). But that will not be as simple as strstr() &
> strcmp() in a line.

In theory, yes, I agree: that approach could be valid. But it would have
to be a universal tree, holding together HTML, JavaScript code, JSON,
JSON-in-JSON, URL-encoded form data and maybe more, in an unambiguous
way. And indeed it would be rather complicated to get all these decoders
to seamlessly play within each other on the same binary stream featuring
several layers of character escaping, to parse all that data into the
common structure, without at any point resorting to buffering very long
text blobs of arbitrary length.

Now in practice, my experience is that the current line-based
free-matching-and-parsing model has not been a real limitation for
lua scripts - on the contrary, the hardcoded limit in the core
stream_ReadLine() is a limitation for the current line-based model.
The only real limitation I hit was when I had to parse and emulate
JavaScript code to descramble YouTube signatures. Keep in mind that this
is code, not data: a JavaScript language parser would be on another
level of difficulty than a data format parser. So again, anything useful
would probably be too heavy and complex to be worth it.

So what problem is this trying to solve?

> A common data structure API can probably expose all parsed data
> formats (tree, nodes, key val properties), callbacks based (because of
> HTML unpaired tags).

As insightful and relevant as the implied new paradigm would be, all
you're really stating is that we can probably parse data into a tree.
Yes, we probably can, but that's a bit of a truism; and this is just
putting forward a tool without a stated problem to fix with it.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."