Jeremy writes...
But the verb mapping is only a minor concern compared to how the HTTP parameters are passed along (see my previous post). And that would certainly require a complete rewrite of the HTTP Bridge (definitely in the category of red-headed step-child code). |
I can see your point of view. Having the parameters as URI addressable resources would be convenient for certain classes of application. I agree that this is a mode that the updated NK3 bridge should support. [continuing the crappy teasers - this is already supported in NK4's bridge].
But stepping back. You've actually inadvertently stood on an intellectual landmine. I'll explain why in a bit. First let me explain why the bridge works the way it does at the moment.
The parameters can be seen as a set of individual resources. They can also be considered as a single entity 'parameters' - that is, we can consider the parameters as a single set. In the current HTTP bridge it treats them as a set - this is the map of name value pairs.
The current bridge makes an engineering compromise and passes the set. As a set the parameters can be transrepted and can be processed collectively - for example I can write a stylesheet to generate a form by operating on the set of parameters (in XML form) as a whole, or I can create a SQL statement by using the parameters as a set in a single statement-generating transform service. From a composite solution perspective each set operation on the parameters can be thought of individually. It turns out that from a system engineering point-of-view this granularity is about right - but it also keeps us out of jail on some deep philosophical intricacies which for pragmatic and sound engineering reasons NK3 hedges on.
To see what I mean lets take 'parameters as individual resources' to the extreme limit.
Imagine you have a form with 10 fields and the bridge processes that into an active URI with 10 named arguments. No problem, very convenient, no need to write any code to operate on the collection - just SOURCE this:param:fieldx or whatever the field is called. (As I said, lets make the new NK3 bridge support this as a mode - it would make some applications simpler).
OK so lets keep thinking about this. Now consider a form with 20 fields or 100 fields or, I've actually spoken to people working on RESTful geospatial mapping applications where they have thousands of parameters and actually run up against the 4K URL browser limit - but that's an extreme case. In principle 20 parameters is still ok for an application. But what about to an XRL mapper layer sitting behind the bridge? Its model is to take a base URI and map it one-to-one with an inner URI and declaratively pass on arguments on the sub-request. Suddenly you've got an explosion of complexity in this declarative code. The developer at this layer has to think about every argument - miss one and the application below fails - brittleness creeps in. Or, as would be more likely the developer decides to use <args>all</args> and passes each one through to be on the safe side. Suddenly the computation required to implement the mapper pattern goes from almost immeasurable to something finite (small probably but definitely a real system cost).
OK. OK. I know this is being provocatively stupid. But bear with me - I'm coming to the point.
Consider another case. What if I have a form and it has repeated field names (actually a pretty common scenario in real world applications). So the bridge splits this up. Does the bridge identify each part with a unique name +field1@...+field2@... etc or does it give them the same name and put them in order? (Oh crap turns out we've stood on a cluster of landmines). Name uniqueness is one of the deep questions in REST and the wider Resource Oriented world. Should the developer code for uniqueness or code for order?
If you code for uniqueness your code becomes tightly coupled and brittlenesss creeps in. If you code for order, who's going to offer the guarantee of order - OK the bridge can guarantee order at the first layer. Does a mapper have to guarantee order? What if the developer writing the declarative argument passing doesn't know the order? Should they? They must if they are going to sub-sample and preserve order? And for sanity you must sub-sample otherwise the layer below's interface has to be as wide as the mappers. But now you've got coupling between layers. Don't even think about the implications of order preservation for rewriting and coding regexs.
Sorry to say that you've left the domain where the kernel should do anything to help either - for many many practical and philosophical reasons the kernel doesn't care what you call anything, the name you give to any resource is your right and responsibility - order within a name is application specific both syntactically and semantically. Imagine the computational overhead of the kernel doing order checking on every request?
We can go further. Should the parameter be addressable more finely? It is represented as a String which is a set of characters. Should that set be individually addressable? If field1 had a value of 'hello'. Should we support EXISTs on this:param:field1:hello ? [
reductio ad absurdum: the characters are actually a representation of integer numbers, from set theory numbers are sets derived from the empty set, the empty set is usually represented as {} so 0={}. 1={{}}, 2={{},{}}={1,1}. What about a really fine grained addressing scheme this:param:field1:{{}}{}}{{}}{{}{{{}}{{}}}{}}}}} or should that be {}{{}{}{}{}{}:{}{}}{}{}{}{}{}:{}{}{{}{{}}}}}}}}}} ?]
Now I'm being deliberately super obtuse to make a deeper point and hopefully to show that we try not to make arbitrary choices. This discussion is an example of something which comes up repeatedly, during the development of the kernel, the address space abstraction and even sometimes with higher order tools like the bridge. We call it 'The Part Whole Dichotomy'. That's a grand name - to use a name like that you're either a pseudo intellectual idiot or you are trying to be very careful and formally correct. I'll let you decide which I am!
What this term acknowledges is that there is a fundamental duality in the foundation of resources. This is nothing new, Plato was the first to recognize this. Is it a can-of-worms or a can containing worms? Is the can a can or a cylinder of metal with two circular ends? Is the metal metal? Or is it an amorphous collection of elemental particles arranged in a representation of the abstract platonic circle form? Are the atoms sets of protons, neutrons and electrons? I'll stop there cos I've forgotten too much physics and I don't know enough about worm biology to keep going.
In the introduction to Resource Oriented Computing paper I stated the first axiom as 'A resource is an abstract set of information'. [Notice 'set']. What I didn't talk about was granularity. What ROC applications are doing is progressively selecting and transforming between sets. As layers of an ROC application go down the granularity with which you want to address resources goes up. Unfortunately there is no one size fits all model for resources. This is where judgement and a bit of experimentation helps and eventually experience lets you take short cuts.
I'm sorry this has been such a laborious essay again. I'll repeat that I understand the pragmatic requirements to add parameter addressing to the NK3 bridge. Hopefully by getting into some detail I've provided a glimpse of the sort of careful step-by-step thinking that we're currently engaged in with the next gen NK work. As another teaser I can say that NK4 addresses and applies itself to these fundamentals of ROC without hedging.
RESTFul HTTP Fulcrum
