Connector URIs
Ross Singer
should only need to send relative URIs to refer to their paths/ids.
[1] This assumption breaks down, however, if the URI needs to be
included in the actual atom entry payload, however. There's no way
for the Jangle core to know when it's appropriate to make a relative
URI absolute in every kind of response format that a connector might
send back.
Which means, I think, that the Jangle core needs to let the connector
know "where it is" with each request (i.e., pass on a 'base uri' of
the connector).
There are a couple of ways of doing this:
1) Pass a query string argument
- This is, obviously, really easy to implement for GET requests.
I'm not sure I like adulterating the user request like this and not
sure how easy it would be implement for POST or PUT (DELETE is like
GET in this regard).
2) Add a request header with the base_uri
- I actually prefer this, but I don't know if it makes creating
connectors more complicated or difficult. Does anybody have any
opinions on this?
Any other suggestions on how to statelessly make a connector know the
path the core is hosting it at?
[1] http://jangle.org/drupal/connector/api/uris
-Ross.
Mike Rylander
I vote for option 2. Every mod_* and CGI framework I've used makes it
easy to get at headers, and this information would only pollute the
main request data with interprocess metadata, IMO, if included in the
main request.
--miker
Ross Singer
-Ross.
Godmar Back
to a specific protocol, and to arcane details ("http request
headers"!) of a specific protocol at that?
When we discussed the form of atom embedding, you've successfully
argued that making changes in the choice of transport should be
facilitated.
Hardwiring http for the communication between core and connectors does
not seem to be a good idea; it'll also make it hard to create more
efficient connectors that may be co-located with the core (and which
could use simple procedure call to get information from the
connector.)
This would be a textbook case of using an IDL (such as WSDL,
potentially); at the very least, make sure you separate in your design
the API (e.g., operations supported, and for each operation the input
and output parameters) from your transport.
- Godmar
Mike Rylander
>
> Why are you tying the communication model between core and connectors
> to a specific protocol, and to arcane details ("http request
> headers"!) of a specific protocol at that?
>
> When we discussed the form of atom embedding, you've successfully
> argued that making changes in the choice of transport should be
> facilitated.
Hrm... I was under the impression that we were discussing what the
jangle core would emit to jangle clients, not the connector<->core
communication, which seems to me is a different problem domain, and
should be much more tightly controlled. Was I misunderstanding?
--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com
Ross Singer
One of the points of agreement was we'd start with a very simple
REST/JSON/HTTP model between connector and core. After we established
the way Jangle would look and act, then we could consider alternative
ways to access connectors.
The HTTP model has a _very_ low barrier for someone to write up a
proof of concept. The introduction of IDLs means that we'd have to be
spending time worrying about how to negotiate with connectors when we
haven't even agreed what connectors should be returning yet.
So, while I think it's generally to include an IDL based approach
eventually, these sorts of infrastructure variations will only hold
back a working prototype right now, I think.
For instance, I think Mike was interested in JSON-RPC.
It's just tough to reconcile everything at once.
-Ross.
On Wed, Jul 23, 2008 at 4:32 PM, Godmar Back <god...@gmail.com> wrote:
>
Ross Singer
> Hrm... I was under the impression that we were discussing what the
> jangle core would emit to jangle clients, not the connector<->core
> communication, which seems to me is a different problem domain, and
> should be much more tightly controlled. Was I misunderstanding?
>
No, this was to let the connector know where it was being served from
so it can construct its URIs properly.
So, in this case, it's connector->core (not quite connector<->core)
-Ross.
Godmar Back
>
> Are you suggesting that HTTP headers are more arcane than WSDL?
No, they're equally arcane, and actually, I'm not advocating WSDL
(which I know little about); my point was more one of a design
philosophy that separates the concerns of functionality from the
actual implementation.
>
> One of the points of agreement was we'd start with a very simple
> REST/JSON/HTTP model between connector and core.
I apologize - this agreement wasn't clear to me. As Mike pointed out,
the communication between core and connector is much more tightly
controlled; hence the motivation for using JSON (which is the least
structured of all possible representations, lacking any way to specify
a grammar or schema) may be weak.
But, by all means, it's not a huge flaw as long as you don't let too
many specifics of this REST/JSON/HTTP model, and particularly the http
transport, become too ingrained.
BTW, what does the O'Reilly REST book have to say about this?
Fundamentally, if something requires an input parameter to form a
correct response, it's not a resource, it's a service, isn't it?
An alternative option would be for the the connector to respond with
some kind of template (e.g. using "${SERVER_RESOURCE_BASE}/..." or
some such) and have the core fill in the correct URL as needed.
- Godmar
Mike Rylander
Heh ... sorry, I was not explicit about which discussion I was
referencing. Godmar mentioned the Atom discussion, and that's what I
was referring to regarding my impression -- that Atom is what jangle
emits to clients, and that /that/ is unrelated to the core/connector
communication. In fact, the connector should not know what form its
data will take after handing it off the the jangle core.
Ross Singer
>
> I apologize - this agreement wasn't clear to me. As Mike pointed out,
> the communication between core and connector is much more tightly
> controlled; hence the motivation for using JSON (which is the least
> structured of all possible representations, lacking any way to specify
> a grammar or schema) may be weak.
Well, the idea here was to keep the communication between the
connector and the core pretty tightly defined. The argument was, with
data that you know the structure a priori (which should be the case
here), JSON would be be much easier to create/consume.
XML schema creation and parsing, for basically passing information
like "what template you should use for this" seemed overkill.
>
> But, by all means, it's not a huge flaw as long as you don't let too
> many specifics of this REST/JSON/HTTP model, and particularly the http
> transport, become too ingrained.
>
While I think the option should be left open, I think I'd need to be
convinced that HTTP wouldn't work for majority of cases. HTTP's big
advantage, of course, is that everything can be written in a
completely different language.
> BTW, what does the O'Reilly REST book have to say about this?
> Fundamentally, if something requires an input parameter to form a
> correct response, it's not a resource, it's a service, isn't it?
Well, this would imply that conneg isn't RESTful, since it relies on
the HTTP_ACCEPT header. While I can't say with any certainty one way
or the other, I would lean towards thinking that conneg and REST
aren't mutually exclusive.
>
> An alternative option would be for the the connector to respond with
> some kind of template (e.g. using "${SERVER_RESOURCE_BASE}/..." or
> some such) and have the core fill in the correct URL as needed.
>
This also would require the core to parse every atom:entry:content
looking for values to replace... it seems easier (and more efficient)
to do that in the connector.
Although if people are horribly opposed to the request header, it's a
viable option.
BTW. I got the header negotiation to work by adding about 30
characters to the core code and one line in the connector code.
-Ross.
townxelliot
Just wanted to make a quick comment on this issue of whether JSON is
an adequate description of the structure of connector responses.
One of the reasons why I think JSON is a good representation is that
it gets you out of this "which XML schema should we use" discussion,
and enables you to think more about the classes and objects in the
domain. I personally find an XML schema painful to use for describing
a domain, and would much rather use a UML class diagram or similar.
Another attractive aspect of JSON for me is that there are off-the-
shelf libraries for turning objects in most languages into a
serialised representation. If you're using XML as the output from the
connector, the connector author(s) may have to work out how to do the
serialisation if there's no decent library for their programming
language to automate the translation.
I agree that HTTP as a transport shouldn't be the only choice: far
more efficient to talk at the code level if the connector and Jangle
core are on the same machine. For a first cut, though, it's a good
choice. But I think standardising on JSON as the output format for
connectors will help us focus the discussion and be more productive.
Elliot
On Jul 23, 10:36 pm, "Godmar Back" <god...@gmail.com> wrote: