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

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.