s/json/XML/ s/json schema/XSD/
And we’re full circle.
I was hoping for some theoretical event-based systems approach, using Pi-calculus to prove correct systems composition.
And we’re full circle.
I was hoping for some theoretical event-based systems approach, using Pi-calculus to prove correct systems composition.
As an Invited Expert at the World Wide Web Consortium between 1996 and 1999, Bray co-edited the XML and XML namespace specifications.
Processes (CSP) [Hoare 1978] proceeds as follows: “Such
communication occurs when one process names another as
destination [to receive a request] and the second process
names the first as source for [the request] ... [in order
that providing the request] is delayed until the other
process is ready [to receive the request].”
Synchronized requesting x with request r (i.e. x!r) can
be implemented as follows using a 2-phase commit protocol:
x.synchronize[Implements Provider ⟦provide ↦ r⟧]
parameter Implements Provider ⟦provide ↦ r⟧, x can get r
from the parameter using a provide message (cf. [Knabe
1992]). Synchronized sending x a request r (i.e. x!r) can be
algebraically reduced (which is a primary requirement of
communication in the π-calculus [Milner 1993]) because x is
provided with r without arbitration by
Implements Provider ⟦provide ↦ r⟧.
Synchronized requesting (i.e. x!r) has the following
significant costs in time, communication bandwidth, and
robustness by comparison with unsynchronized requesting (i.e. x.r):
1. The requester must wait for the receiver’s provide
message in order to provide request r.
2. After receiving a synchronize message, the receiver
must wait for the request r to be provided
(meanwhile holding up processing of other requests).
3. Both the requester and receiver must be online
concurrently for communication to take place.
reduced using an algebraic equation as in [Milner 1993]
because in general, the request must go through arbitration
in order to be received. Although algebraic reductions may
be elegant mathematics, synchronized requesting is not
widely used in large software systems because it is slower,
uses more communication bandwidth, and is less robust than
asynchronous requesting (especially for IoT).
But out of interest, the syncing that you apparently dislike but which actors sidestep by having a receiving queue, said syncing allows for messages to be processed when the receiver is ready (obviously). That's a time overhead. If actors have unbounded queues then there's a memory overhead (and one which may grow infinitely on a finite machine if someone isn't processing their messages fast enough).
How do actors handle that? If I'm talking rubbish some reading matter is welcome.
Ideally, a message sent to an Actor is never stored in persistent memory. A runtime system should never accept a unbounded backlog of communications for an Actor. Instead worst case, it should generate exceptions for further requests.
Here are references that you requested:
> If actors have unbounded queues then there's a memory overhead (and one which may grow infinitely on a finite machine if someone isn't processing their messages fast enough).
Depending on the Actor implementation one employs, this concern can be mitigated. For example, Akka[1] provides BoundedMessageQueueSemantics[2] which can be used to provide hard limits.
0 - https://en.wikipedia.org/wiki/History_of_the_Actor_model
1 - https://doc.akka.io/docs/akka/current/typed/index.html
2 - https://doc.akka.io/docs/akka/current/mailboxes.html#requiri...
http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...
Reposting:
https://news.ycombinator.com/item?id=20384206
He's not that famous outside of hard core geek circles, but I am a huge fan of James Clark (not the SGI guy, but he's awesome too for different reasons), who wrote the Expat XML parser, Relax/NG XML schema language, and many other widely used standards and bodies of code that drive the Internet.
He has such clarity of thought and mastery of diverse languages (some of which he invented and implemented). He saw exactly what was wrong with XML Schemas, and addressed it practically and elegantly with TREX, which he and others refined through humble constructive collaboration into Relax/NG. And he's a big proponent and creator (not just a talker like ESR) of free open source software.
Here's a fascinating insightful DDJ interview of James Clark, "A Triumph of Simplicity: James Clark on Markup Languages and XML":
http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...
>A Triumph of Simplicity: James Clark on Markup Languages and XML
>If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade.
>Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center (http://www.thaiopensource.com/). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity.
[...]
>DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works?
>JC: Having a reference implementation that's too good can actually be a negative in some ways.
>DDJ: Why is that?
>JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate.
>You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation.
>DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same?
>JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.