ich folge immer noch aufmerksam der [create XMC] debatte. und mir scheint, dass da im fundament probleme sind. eventuell laesst sich XML-RPC schlicht und ergreifend nicht absolut sauber upgraden. (hint: eine ganz kurze zusammenfassung folgt ganz am ende :)
ganz generell: um die debatte ueber die art und weise der implementation eines XML-RPC nachfolgers vernuenftig fuehren zu koennen, ist ein grundlagenpapier fuer diesen absolut notwendig. ein pflichtenheft, eine liste an muss-kriterien die dieser nachfolger erfullen muss.
adam megacz (der initiator von [create XMC]) listet zwar ein paar punkte als rationale fuer seinen entwurf auf. in "relationship to XML-RPC" sowie "implementation requirements" finden sich ebenso phrasen die zu muss-kriterien werden koennten. ganz generell fehlt mir dieses grundlagenpapier allerdings.
mir scheint (!) es darum zu gehen, einen nachfolger zu XML-RPC zu finden, der gar nicht gefunden werden kann. der erfolg den XML-RPC fuer mich darstellt, besteht darin, dass ein least common denominator an datentypen gefunden wurde, der immerhin in ueber 40 umgebungen befriedigt werden kann.
all those environments are able to talk to each other!
das ist der kern. dave wuerde es die "inclusive nature" nennen. XML-RPC ist eine gemeinsame grundlage und eignet sich daraus als solche nur bedingt fuer spezialisierte anwendungen.
und mit verlaub, aber hochpraezisionsarithmetik und doppelt verkettete listen passen da nur schwer ins bild. wenn environment X nun einmal mit uebergrossen zahlen nicht umgehen kann, dann kann es das nicht. und "multi-ref data" ist halt fuer einige environments auch ein unimplementierbares ding. wenn sowas benoetigt wird, dann muessen sich die peers halt eigene protokolle ausmachen.
zusammenfassend, fehlt meiner meinung nach einfach der grundkonsens "was wollen wir hier (XMC) eigentlich machen." XML-RPC zur eierlegenden wollmilchsau zu machen, scheint mir absolut fehl am platz.
ein weiteres faktum erschwert die klare sicht auf die dinge: XML-RPC hat seine fehler. die mangelhafte unicode integration ist davon der einzige wirklich schwerwiegende. die unspezifiziertheit von empty calls und empty responses sind zwei weitere, harmlose. das restriktive (in jedem sinne) binding an HTTP ist eine annoyance, aber kein hindernis. ein paar kleinere formulierungsschwaechen schliessen die fehlerliste auch schon wieder.
die mangelhafte unicode integration wollen wir nun auch noch kurz im weiter oben erlaeuterten kontext zu betrachten. fuer einige der jetzigen XML-RPC implementation mag unicode ebenso eine killer anforderung sein. nur erscheint mir unicode in einem hoch integrativen protokoll als dermassen grundlegend, dass diese entrance barrier in kauf genommen werden muss. meiner meinung nach die einzige wirklich huerde die XML-RPC haben sollte. nachdem texte und strings den wohl meisttransportierten datentyp darstellen (rein dem gefuehl nach, kann ich nicht belegen), sollte hier das augenmerk liegen. und nicht auf doppelt-verketteten listen.
resume - XML-RPC hat tatsaechlich probleme. beim ansatz diese auszuraeumen geraten die ausraeumenden leider allzuoft in die versuchung XML-RPC universell zu generalisieren, die sprichwoertliche eierlegende wollmilchsau daraus zu machen.
welche moeglichkeiten bestehen nun aber, die fehler wirklich auszuraeumen? bald mehr dazu, hier auf esa :)
no comments
Please log in (you may want to register first) to post comments!
search
backlinks (more)
none, yet
recent stores (more)
recent comments
echo earlZstrainYat|tr ZY @.
