[146455] in cryptography@c2.net mail archive
[Cryptography] Source for protocol compiler
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Aug 28 17:04:22 2013
X-Original-To: cryptography@metzdowd.com
Date: Wed, 28 Aug 2013 16:24:29 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2147866669758241657==
Content-Type: multipart/alternative; boundary=089e013c6760c5856304e507c68f
--089e013c6760c5856304e507c68f
Content-Type: text/plain; charset=ISO-8859-1
The source is up on sourceforge now. It does need some spring cleaning and
documenting which I hope to get to next week.
The documentation is in the following directory
https://sourceforge.net/p/jsonschema/code/ci/master/tree/Web/
The origins of this work is that about 70% of the effort in working groups
goes into debating 'bikeshed' type issues (as in what color to paint it)
that really don't matter. Things like choice of encoding (just use JSON) or
binding (Any reason to not use HTTP + SSL) and so on.
And 70% of the effort of the editor would go into making changes to the
spec which would need to be reflected accurately in six different parts of
the document and the reference code and then conformant examples generated
and inserted at the right place and then other folk would have to check it
was all done right.
So JSONSchema converts an abstract schema definition (in a programming
language syntax, not JSON encoding!) and produces a stub client API and a
stub server with the appropriate holes to plug in your semantics. You can
then write documentation and insert examples from running code (provided
you like documentation in either HTML or Internet Draft format at the
moment).
It is all written in C# and has been run on OSX and Linux under Mono
(binary distributions to follow). The synth currently only generates code
in C# but I plan to add C and probably Objective C down the line. The
meta-synthesiser is also on sourceforge and open source:
https://sourceforge.net/projects/goedel/
The compiler only supports RPC like interactions at the moment, i.e.
query/response. But I am planning to expand the generator to support an
additional interaction pattern in which the client opens a transaction and
receives a series of async callbacks. That would be suited to supporting
chat like protocols.
One of the things I realized as I was doing all this is that all Web
Services really consist of are glorified RPC calls in a different syntax.
The code generated right now is targeted at being reference code but there
is no reason why the synth should not generate production code.
--
Website: http://hallambaker.com/
--089e013c6760c5856304e507c68f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The source is up on sourceforge now. It does need some spr=
ing cleaning and documenting which I hope to get to next week.<div><br></di=
v><div>The documentation is in the following directory=A0</div><div><a href=
=3D"https://sourceforge.net/p/jsonschema/code/ci/master/tree/Web/">https://=
sourceforge.net/p/jsonschema/code/ci/master/tree/Web/</a></div>
<div><br></div><div>The origins of this work is that about 70% of the effor=
t in working groups goes into debating 'bikeshed' type issues (as i=
n what color to paint it) that really don't matter. Things like choice =
of encoding (just use JSON) or binding (Any reason to not use HTTP + SSL) a=
nd so on.</div>
<div><br></div><div>And 70% of the effort of the editor would go into makin=
g changes to the spec which would need to be reflected accurately in six di=
fferent parts of the document and the reference code and then conformant ex=
amples generated and inserted at the right place and then other folk would =
have to check it was all done right.</div>
<div><br></div><div><br></div><div>So JSONSchema converts an abstract schem=
a definition (in a programming language syntax, not JSON encoding!) and pro=
duces a stub client API and a stub server with the appropriate holes to plu=
g in your semantics. You can then write documentation and insert examples f=
rom running code (provided you like documentation in either HTML or Interne=
t Draft format at the moment).</div>
<div><br></div><div>It is all written in C# and has been run on OSX and Lin=
ux under Mono (binary distributions to follow). The synth currently only ge=
nerates code in C# but I plan to add C and probably Objective C down the li=
ne. The meta-synthesiser is also on sourceforge and open source:</div>
<div><br></div><div><a href=3D"https://sourceforge.net/projects/goedel/">ht=
tps://sourceforge.net/projects/goedel/</a><br></div><div><div><br clear=3D"=
all"><div><br></div><div>The compiler only supports RPC like interactions a=
t the moment, i.e. query/response. But I am planning to expand the generato=
r to support an additional interaction pattern in which the client opens a =
transaction and receives a series of async callbacks. That would be suited =
to supporting chat like protocols.</div>
<div><br></div><div>One of the things I realized as I was doing all this is=
that all Web Services really consist of are glorified RPC calls in a diffe=
rent syntax.</div><div><br></div><div><br></div><div>The code generated rig=
ht now is targeted at being reference code but there is no reason why the s=
ynth should not generate production code.=A0</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div></div>
--089e013c6760c5856304e507c68f--
--===============2147866669758241657==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2147866669758241657==--
