[Nitro] An implemention of Orbjson in Nitro

[James Britt]

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:

www.mysite.com/service/jsonrpc


> 
> - 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 
not.

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.

> 
> thanks,
> George.
> 
> 
> 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

http://mysite.com/foo

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?


Thanks,


James


-- 

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com