start | find | index | login or register | edit
by earl, 7174 days ago
braindump in progress ... please comment to comments-xmlrpc-spec-proposal

2001-03-30: straightened Content-Length explanation
2001-04-03: added version attribute suggestion
2001-04-03: added nil problem

xmlrpc-spec-proposal-intro gives a german introduction to why i started writing this snip. the conclusion of this introduction:

we have no interop in xmlrpc land (yet) - let's tighten the spec and let's harden the validator!

an implementation-status overview is in xmlrpc-spec-status.

enhancement suggestions:
  1. hinzufuegen eines 'version' attributes zum methodCall respektive methodResponse element. ab zukuenftiger version der spec fuer clients 'pflicht'; server muss das fehlen des attributes tolerieren. server koennen somit leicht checken wieviele clients welcher version sie haben. - die 'doing it the xml-way' loesung waere natuerlich namespacing.

punkte die missfallen und aerger erregen (und damit auch probleme erzeugen):
  1. A User-Agent and Host must be specified.

  2. The Content-Type is text/xml.

  3. The Content-Length must be specified and must be correct.

  4. i4 or int

  5. If no type is indicated, the type is string.

  6. How to encode empty calls?

  7. How to encode empty responses?

  8. Can a struct contain two elements with equal names?

  9. State that int is base10 encoded (just for the sake of completeness)

  10. nil element

ad a.) why the heck needs an user-agent to be specified?
but because there's a must in there, implementations must be validated according to a). the validator simply ignores this requirement which leads to no-interop between 'lazy' implementations - that leave out the header - and 'hardass' implementations - that raise an exception when these headers are not present.

suggested solutions: add validator checks. optionally let the User-Agent requirement go.

ad b.) the same as in a. hardass implementations do not interop with lazy implementations.

suggested solution: enhance validator.

ad c.) this requirement enforces building up the request completely before transmitting it over the wire; on one hand this has a minor impact on performance, on the other implementations for embedded devices may have their problems with that. anyway, the same problem here as in a and b. hardass vs. lazy. the validator seems not to to check if the content-length field is right.

suggested solutions: let the requirement to away or at least harden the validator.

ad d.) why do we need both? keep it slim ;)
ad e.) what's the use of this option? keep it slim ;) as xmlrpc is everything but not 'slim over the wire' i think the optionality of this leads to nothing but to slightly bigger/more complex server implementations.

ad f.+g.) these issues are not clearly specified yet - but their impact on interoperability is quite severe.

ad h.) no it can not as it makes no sense in any way. struct's are (imho) name-value mappings; having equal names with different values only makes sense under very peculiar circumstances.

suggested solution: clearly state that in the spec.

ad j.) i can't come up with any use for adding a nil value-element. although there are discussions whether it should be added to the spec.

suggested solution: show me a use for nil!

braindump in progress ... please comment to comments-xmlrpc-spec-proposal
powered by vanilla
echo earlZstrainYat|tr ZY @. • esa3 • online for 7204 days • c'est un vanilla site