Scott Lystig Fritchie
Gemini Mobile Technologies
Scott Lystig Fritchie met his first UNIX system in 1986 and has almost never met one since that he didn't like. A career detour as a UNIX systems administrator got him neck-deep in messaging systems, e-mail and Usenet News. He rediscovered full-time programming while at Sendmail, Inc., where a colleague introduced him to Erlang in 2000. His world hasn't been the same since then.
Now at Gemini Mobile Technologies, Inc., he's back in the messaging world. He's finishing a distributed key-value database with strong consistency semantics, micro transactions, and on-the-fly resizing, all in Erlang. In addition to hacking Erlang code and occasionally the Erlang virtual machine, he's had papers published by USENIX, the Erlang User Conference, and the ACM.
Now at Gemini Mobile Technologies, Inc., he's back in the messaging world. He's finishing a distributed key-value database with strong consistency semantics, micro transactions, and on-the-fly resizing, all in Erlang. In addition to hacking Erlang code and occasionally the Erlang virtual machine, he's had papers published by USENIX, the Erlang User Conference, and the ACM.
Scott Lystig Fritchie is Giving the Following Talks
Putting UBF to work (and Getting the outside world to talk to Erlang)
Many protocols have formal specifications: ASN.1, ONC-RPC, CORBA, AMQP, Thrift, Protocol Buffers, zillions more....
We believe there are at least three reasons why industry uses such specifications. However, most industrial uses take advantage of the first mostly and only occasionally the second: #1 Specify bits "on the wire" in a way all parties agree. #2 API documentation: how the protocol's API works. We have found that there's a very important third reason: #3 Protocol meta-data: input for other tools (development, testing, etc.).
My company is one of several that is collectively building a custom Webmail system for a large carrier in Asia. (The initial deployment will be used by well over 1 million customers.) We definitely take advantage of reasons #1 and #2 to facilitate the multi-way project planning with several development groups and the carrier/customer. Their value in communicating both with developers and with project managers is quite large.
We would like to share with other Erlang developers our experiences of using and enhancing UBF for reason #3. Much of this work is slowly making its way into the wider world, using an MIT license and distributed via GitHub (http://github.com/norton/ubf/tree/master).
We believe there are at least three reasons why industry uses such specifications. However, most industrial uses take advantage of the first mostly and only occasionally the second: #1 Specify bits "on the wire" in a way all parties agree. #2 API documentation: how the protocol's API works. We have found that there's a very important third reason: #3 Protocol meta-data: input for other tools (development, testing, etc.).
My company is one of several that is collectively building a custom Webmail system for a large carrier in Asia. (The initial deployment will be used by well over 1 million customers.) We definitely take advantage of reasons #1 and #2 to facilitate the multi-way project planning with several development groups and the carrier/customer. Their value in communicating both with developers and with project managers is quite large.
We would like to share with other Erlang developers our experiences of using and enhancing UBF for reason #3. Much of this work is slowly making its way into the wider world, using an MIT license and distributed via GitHub (http://github.com/norton/ubf/tree/master).