[erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language

[Jakob Praher]

Am 20.02.12 19:51, schrieb Fredrik Svahn:
>> To me, the most natural Erlang representation of a DOM object is the
>> same as for any "object": it's an Erlang process. Now, I can't have an
>> Erlang process in the browser itself (unless someone writes a web
>> browser in Erlang, or implements Erlang in the browser[*]). But I
>> *can* have Erlang processes on the server side, to interrogate and
>> update page state as if its corresponding DOM objects were all Erlang
>> processes.
> Actually, in the version of browserl[1] I checked in a week ago, a DOM
> object is a (pseudo-)process. At one point it was even possible to
> send messages to it (e.g. to request an update) but that doesn't work
> any longer. I might revisit the idea later if/when I get the time.

IMHO a DOM object is a data structure (term) therefore I would be more
interested in composable abstraction over these terms, much like a
parser abstracts over concrete syntax.

But if we are at it: How would you model a browser, if you could write
it in Erlang?  To me a browser could be described as a hierarchical term
storage process (the document) plus a render process that creates
controls owned by the window. Terms are updated through the storage and
it is the rendering process that presents the udpates to the user.
Controls would be process nodes under the window that again change terms
in the storage. Only the owning window is allowed to access the term
storage, making it possible to have mulitple windows with private term
storages.

The term storage process could even be a protected distributed process
that can be shared between the client and server side. If the server
sends passes mutating messages to the storage process, the client can
directly reflect these.