http://www.haiku-os.org

Going off of the sql section for a simple example:
alter table tableparams
tableparams: add … | del … | etc…

It would be sweet if tableparams showed up as a folder type of icon that you can collapse/expand.

I’ve read your “Gazelle” blog and the Gazelle manual, and amen!

I was sick of language in the style of ANT/MAVEN pseudo-language XML-Hell.

For doing some language transformation and some DSL (in my day job), I was looking into parsing.

I’ve looked into ANTLR (pragmatic book) but something didn’t fit: the embedding of action into the grammar file (I have to redo the grammar file if I want to generate in another language ? WTF)

The other solution I found is doing the grammar inside the language like Parsec from the Haskell World, no more beautiful (very common for DSL in the Lisp world too).

I found about GOLD in your blog, look good, but since it is a Windows-only thing…

So basically no tools fit my need, maybe Gazelle at version 1.0
Question:
Have you any rational for your grammar syntax ? Instead of using BNF/EBNF of SDF ?

I will look into your release 0.2,
Thanks for the good work.
(note: I can’t get the formating of my comment correct…?)

You have wonderfully substantive arguments, as always! To address them fully I’ll need to write a full blog entry. There’s just one thing I want to answer at the moment:

I wasn’t trying to claim that there isn’t software that implements RESTful services, proxying, caching, wire formats, etc.; of course there is. I just wanted Steve to pick an actual implementation of one that he thinks fairly represents the REST ideal, so we could compare apples to apples (one request/reply implementation to another) and make objective comparisons like:

- what does “Hello, world!” look like?
- how do you document and support your APIs?
- how does the system handle various failure modes?
- how much work does it take for others to interoperate with you?
- how well can the system support adjusting the caching strategy?

What I wanted to avoid is going down a path of discussion where I would say “REST doesn’t support scenario X very well” and hear a retort like “the REST stack could support a feature that does X perfectly.” I want to talk about reality and not Plato’s world of forms. I want to compare actual implementations and not architectural ideals.

Anyway, I’m on the fence about whether I want to take the time to really thoroughly explain my point of view right now. On one hand, this has been on my mind for a while. On the other hand, this discussion has started to wear on me a bit and I really desperately want to get the next version of Gazelle out the door.

This is really a response to this comment thread, but I thought I’d converse with you directly rather than via Steve’s blog.

RESTful HTTP is not software. I can’t download, compile, and develop with it.

Sure you can. Oh, but other software is available that does REST on HTTP? That’s a bad thing? If someone wrote a pure-Java ICE stack that interoperated with the original, would that make ICE a worse choice, or a better one?

It’s true. REST - even a specific RESTful architecture like Ruby and Richardson’s ROA, on a specific protocol like HTTP - does not constrain you to a single software implementation.

But I’d say that it’s actually the other choice that’s underconstrained. RPC-like middleware frameworks like ICE and Thrift may provide plenty of guidance as to what software needs to run on each end of the connection, but they are completely unconstrained when it comes to the hard questions of desiign and architecture. What should my API look like? Should session state be maintained by the server or the client? How are state changes represented? How does data point to other data, possibly in other services? REST answers all of these. ICE and Thrift leave it up to the developer to design client-server interaction patterns. (At least some of the REST constraints can be followed within an RPC-like system, and should be for any system that has to scale and interoperate).

I’m still left deciding what my on-the-wire format will be.

Not true. HTTP has a wire format, just like the request-reply system I mentioned above does. HTTP’s format is richer in some ways, and poorer in others. Both include extensible metadata. HTTP’s wire format also defines semantics for things like modification and expiry dates, authentication tokens, retry counts, character encoding, redirections to other services, and data fields whose formats are described by MIME types. The proprietary system allows only one format for its data fields, but this data format maps better onto some popular programming language data structures than the common MIME types used with HTTP.

But if you do want to pass simple RPC-like parameters through HTTP without referencing a separately-specified data format, the URI specification gives the standard way to do this for HTTP GET (using URI-encoded parameters in the query string), and the “application/x-www-form-urlencoded” MIME type is a default format for use with HTTP POST. Neither is really that great as serialization formats go, but I’ll freely admit that taking full advantage of HTTP does require the designer to choose an appropriate content-type for the data being transferred. On the other hand, most middleware systems work much more poorly with content types that do not match their native formats.

Even if I choose an on-the-wire format like JSON (and choose an implementation of JSON) I still need more code to actually dispatch incoming requests to my request handlers.

Sure, if by “write” you mean “download a widely-deployed piece of software like Rails that will generate it for me.” The same is necessary with the main RPC-like framework I’ve worked in, by the way. Anyway, it’s not like any system is just going to let you download third-party software without writing some of your own to handle your specific logic for each request. Fortunately, both HTTP and ICE-style frameworks have implementations that will take care of the boring boilerplate parts like dispatching for you.

(In fact, Apache alone *is* a perfectly good dispatching system for many purposes - I’ve implemented quite a bit of functionality for some applications just using mod_rewrite and CGI.)

And if you’re making the traditional “caches, proxies, and tunnels, oh my!” arguments that REST advocates make, you’ll need yet more software to actually give you these things.

I’m not sure why you seem to think this is hand-waving. Every large-scale HTTP service I’ve seen (except the ones that are just tunnels for proprietary request-reply protocols!) makes use of HTTP caching, and most make use of proxies. I personally am responsible for four different services that publish feeds over HTTP, and four different applications that consume those feeds. These eight programs, implemented in three different languages, all see improved latency and decreased bandwidth thanks to their common support for HTTP’s cache expiry and validation.

With every HTTP library I’ve used, caching is built in - no need for separate software. Yes, if you decide to introduce proxies into your architecture then you’ll need to choose one to meet your needs. Again, I’m not sure why you think it’s a bad thing that the client/server framework doesn’t commit you to using just one proxy implementation.

Since nothing you write is a substantive critique of my blog entry, there’s not really anything more to say

Frankly there is nothing much to critique in your blog entry. There are no technical arguments to say why RPC is better while the rest of the industry is moving more towards message oriented middleware. All you have done is to say Facebook and Google is using RPC in the backend. Dude, simply bcos it’s Google or Facebook do you automatically believe that RPC was the best choice? Have you considered how different it may have been if they used a message oriented approach? Do you know the advantages/disadvantages each approach would have yeilded for the given systems. If you do have them please state and we can have a good debate about it. Simply bcos something works does that mean that is the best way to do it?

Yes, on a network shit happens, and no sane RPC system will try to hide this from you.

I think you got the definition of RPC wrong. RPC by definition provides the illusion of calling a routine on a remote address space looks as if it resides in the local address space. As a programmer you write the same code whether the routine is local or remote. If my remoting framework doesn’t hide the network from me, then I am doing something else not RPC.

Adding a new parameter? No problem, old servers simply won’t see it.

If only a developers life is this easy. Here are some use cases taken from the thrift white paper

Added field, old client, new server. In this case, the old client does not send the new field. The new server recognizes that the field is not set, and implements default behavior for out-of-date requests.
Removed field, old client, new server. In this case, the old client sends the removed field. The new server simply ignores it.
Added field, new client, old server. The new client sends a field that the old server does not recognize. The old server simply ignores it and processes as normal.
Removed field, new client, old server. This is the most dangerous case, as the old server is unlikely to have suitable default behavior implemented for the missing field. It is recommended that in this situation the new server be rolled out prior to the new clients.

You can see from case 4 that adding a paramter is not as easy as you think. If it was such an easy from problem to solve then why is thrift (which is what Facebook is using and one of the systems that you seem to toot about) is recomending that you need to roll out a new server?

Completely changing the semantics of your call? No problem — just give the new call a new name.

Try telling that to your manager when the system is already in production.