Re: RFC: markdown to HTML library

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2014-01-20, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Sun, 19 Jan 2014 22:26:04 +0000 (UTC), Natasha Kerensikova wrote:
>
>> Features request are welcome too, though I can't tell for now when I
>> will manage to look into them. Currently reStructuedText front-end and
>> and fully-configurable ODT back-end are on my radar.
>> 
>> I can get into the details of how it works internally, but I won't bore
>> you with it if it's not necessary.
>
> There are many different requirements depending on the usage, I guess.

Indeed, but it feels like I'm a lunatic doing crazy stuff that nobody
cares about or is interested in, so the only requirements that really
matter when I write code are mine.

Then when someone does not want to roll their own library, they compare
their requirements against what is provided in existing libraries they
know about. And the actual code and what it can handle is of no matter
when you can't make it to that list.

> Now to the way my HTTP server works. The content is generated and not
> stored in a file, though the latter is possible of course. That is because
> the server is intended for embedded platforms, which may have no disk space
> or it could be undesirable to write anything on the disk.
>
> For the same reason the content should be fed to a state machine in pieces
> that fit into the outgoing buffer. This is because the server does not
> allocate memory dynamically by itself and because it is driven by the
> buffer-ready event.
>
> So the library for generating content should be able to work in the
> corresponding manner. E.g. upon a GET request the content must be prepared
> and its sending only initiated. Then another time on another context chunks
> of the content are sequentially requested as they are sent away. I.e. the
> thing must maintain internal state and not spilling all guts in one shot.

In such a situation, I would strongly advise against Markdown in the
first place, because the language doesn't really lend itself to bounded
environments, with its references that could be explicitly absolutely
anywhere within the source, some language elements that require
unbounded look-ahead to be distinguished, etc.

So if were in charge of such a webserver, I would first try to negotiate
my way out of supporting Markdown.

If supporting Markdown were an absolute requirement, I would try to
process it outside of the webserver (on client side, on dedicated
unbounded side machines, etc).

And if supporting Markdown inside the bounded webserver were an abolute
requirement, I would try negotiate the removal of the most problematic
language features (URL references, lists of blocks elements, etc) and
with carefully chosen upper bounds it might be possible. However I'm
afraid that even then, it would be beyond what is achievable with my
current programming skills.


Now as far as my library goes outside of Markdown, there is nothing
structurally that prevents it from being totally bounded. So it is
certainly possible to write bounded front-ends and bounded back-ends
that can fit within your constraints.

The HTML back-end is actually not that far away, the only current
blocker is the mechanism to share the internal state between all
language element instances, which involves dynamic allocations. But with
well-written storage pools, I believe even this mechanism could be used
in your environments. So you would only lack a front-end to make use of
my library.


Thanks for the discussion,
Natasha