SPAM: Re: SPAM: Re: [OPEN-ILS-DEV] Full OpenSRF over HTTP

[Bill Erickson]

Mike Rylander wrote:
[snip]
>>> Changes to OpenSRF
>>> ==================
>>>
>>> Stateful communication with backend OpenSRF service instances will be made
>>> possible by giving each service the ability to accept "migratable" client
>>> remote IDs.  If the configuration section for a given OpenSRF application
>>> has the setting
>>>
>>>    <migratable-clients>true</migratable-clients>
>>>
>>>       
>> Monty Python aside, how would you feel about "migratory-clients"  (or
>> mobile-clients)?  I'm pretty sure "migratable" isn't a word.
>>     
>
> Well, "not being a word" has never stopped us before, but I'm not
> married to the terminology.  Something to keep in mind is the symmetry
> with session and transaction migration on the server side (on the
> roadmap),  and (to be a pedant about precision) clients aren't mobile,
> nor forced or guaranteed to migrate (implied by "migratory") ... I
> guess I'd like something softer -- "client might move, but that's OK."
>
> I consider it an open question at this time.
>   
Ahh, yes.  Point taken.  Unless there is some English equivalent, 
"migratable" works for me.


[snip]
>> I have an incomplete, yet, thus far, functionally equivalent prototype
>> running on dev.gapines.org.   The example Javascript is at
>> http://dev.gapines.org/~erickson/multi/multi.html.  (Warning, produces
>> several popups of raw JSON output and only works in Mozilla/FF).  The
>> headers are slightly different (X-OSRF instead of X-OpenSRF) and I'm not
>>     
>
> At first I had no objection to whatever string was used for the
> headers, but I think now that being more explicit is better.  Also, we
> need to come up with a convention for all parts of the header.  Your
> current code uses "X-OSRF-To" where the proposal says "X-OpenSRF-to".
> All else being equal, I feel like the proposal version of these
> differences has some more weight to it if only because it is a form of
> documentation that can be pointed to, and it's easier to update the
> code to match the docs (certainly for things like this) than the other
> way around, since the code is more actively worked on.
>
> So ... objections to changing the prototype code's format of the headers to
>
>  X-OpenSRF-<lowercase-descriptive-component>
>   
+1 for the more explicit X-OpenSRF-<lower> format.

-bill

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com