[Nitro] An implemention of Orbjson in Nitro
james_b at neurogami.com
Fri Mar 25 09:29:35 EST 2005
George Moschovitis wrote:
> Hello James,
> thanks for this code snippet and for your efforts! This example looks
> cool, I especially like the auto registration thing. By the way I 'll
> add a correct get_raw_post method. Do you need something else?
> Some remarks:
> - what is the URL to call this service?
> Something like:
> www.mysite.com/service/jsonrpc/example/times/x ?
> how does the x parameter get passet to the times method?
The requests are done using HTTP posts. The remote method name and all
parameters are bundled up in the json-rpc message sent in the post data,
so all calls use the same URL:
> - why do you use Needle? Is this really useful? It *seems* to be
> useful but I still cannot understand why.
I had written my own simple object registry to store service objects
(basically a Hash), but felt it was too simplistic, and saw that Needle
had essentially do what I wanted (plus more, really). Rather than
continue to hack features on to my object registry, I decided to just
reuse Needle. Less code for me to maintain.
It isn't essential, of course What's needed is a way to map json-rpc
requests to objects. Needle just happens to make that easy.
> - Can we find a sorter/better name than ORBJSON / JSONRPC ?
JSON-RPC is the name of the remote method invocation format. My library
implements an object request broker that routes json-rpc requests to
objects and marshals back the response. Orbjson was just a name I picked
for my library.
There's nothing too remarkable going on here (a feature I like), I
pretty much jut teamed up Jami Buck's Needle with Florian Franks
Ruby-JSON; it may be better to just write a version specially for Nitro.
I prefer, though, to think in terms of how independent libraries may be
wired together, such that people need only install and use the parts
they need, and others can use the libraries for their own
apps/frameworks without having to buy into all the other parts.
It may seem trivial, but I find it odd that in order to write a really
simple database-backed Web site using Rails I have to install a mailer
library, a Web services library, an AJAX lib, etc. whether I use them or
I would prefer to see a system where I am only prompted to install code
once I run a generator script that creates a dependency.
> ps: seems to me you played quite a bit with Nitro. If you have found
> methos/parameters that could be named better, or snippets of code that
> could be improved please let me know. Nailing the API down is very
> importance at this moment.
One thing that had me confused was how to add new controllers. After
doing a contract job with Rails I cames to expect that simply defining a
class as FooController would automagically make that class available as
But I found that I could only get it to work if I explicitly registered
the class with the dispatcher. But maybe that's a good thing.
Recently, Hal Fulton posted a message to ruby-talk about object
databases. I started a response, but didn't send it, as I was concerned
that it may sound a bit too snarky (more snarky than I often am, I'm
afraid). The point I was after was that writing an application where
your object model was strongly influenced by your database model was a
development problem because of the paradigm mismatch.
Maybe my understanding of Rails is not all that good, and I can imagine
ways to add extra layers of abstractions to avoid getting stuck with a
rigid object <-> DB mapping. But I was also reminded of a talk Avi
Bryant gave at RubyConf 2002 (I think) on Borges. He started off
showing a typical command-line application, with persistent state and
such. He rhetorically asked the group how much more work would be needed
to turn this into a Web application, then added one line of code.
The crowd though this was trickery, and it was , of course, but he then
demonstrated how that one line called into his Borges library, which
used continuations to maintain state in a Web application.
What struck me about this, and where I think this may apply to Nitro, is
that one could go write an application blissfully unconcerned for
certain operating aspects, such as whether or not the code would be
standalone or on the Web. There was no need to think about any of the
environment scaffolding (state, templates, markup, and all the usual Web
stuff) until you were ready. And what attracted me to Nitro was the
idea that I could write an application without concern for the
persistence model, creating my objects based on business logic, not
data. Then, later, I could decide how to persist the data. The objects
drove the database, not the other way around.
But this approach may mean that you don't get certain things for free,
simply based on naming or other coding conventions, because the
philosophy behind the library is that your code should not carry too
much default behavior . You write your code as you wish, then go add
certain items (top-level method calls, 'requires', or something) to
magically add in persistence, or Web behavior, or concurrency, or
whatever the case may be.
So, when you ask about suggestions on API design, I think I'm a bit
unclear as to what the driving philosophy behind Nitro is, so I can't
really say if it is proper to expect, for example, that classes with a
certain naming convention should automatically acquire certain behavior.
Hope this made at least a little sense, and if I've grossly
misunderstood something please straighten me out. But it seems that
Nitro/Og, and Wee, and perhaps other projects (maybe Orbjson), are or
could be geared to this "don't commit to an operating environment until
the last moment" style of development.
With Rails, it is assumed right from the start that you plan on writing
a database-backed Web application, where the data is what drives the
site. Nitro/Og seems to turn this around, though there is still the
assumption (I think) that you plan on using a database of some sort and
presenting on the Web. Suppose you had no idea, or you have existing
command-line applications that had no data persistence. Is it, or
should it be, a purpose of Og/Nitro to make it easy to layer on Web
presentation and a database back end?
More information about the Nitro-general