xmlrpc-spec-proposal
by earl, 8662 days ago
braindump in progress ... please comment to comments-xmlrpc-spec-proposal2001-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:
- 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):
- A User-Agent and Host must be specified.
- The Content-Type is text/xml.
- The Content-Length must be specified and must be correct.
- i4 or int
- If no type is indicated, the type is string.
- How to encode empty calls?
- How to encode empty responses?
- Can a struct contain two elements with equal names?
- State that int is base10 encoded (just for the sake of completeness)
- 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
search
80 active users
- unknown (80)
recent stores (more)
echo earlZstrainYat|tr ZY @.
