|start | find | index | login or register | edit
by earl, 8371 days agobraindump 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.
punkte die missfallen und aerger erregen (und damit auch probleme erzeugen):
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
7 active users
echo earlZstrainYat|tr ZY @.
|earl.strain.at • esa3 • online for 8401 days • c'est un vanilla site