W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010


From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Fri, 24 Sep 2010 20:35:47 -0700
Message-ID: <AANLkTikMyHdK=6Pf6G7auC-R9260j-T=UimHpQt3NDCs@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Adam Barth <w3c@adambarth.com>, Ojan Vafai <ojan@chromium.org>, Darin Fisher <darin@chromium.org>, Garrett Smith <dhtmlkitchen@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, WebApps WG <public-webapps@w3.org>
> If you really don't want to care what happened before, either do a
> clearParameter every time first, or define your own setParameter that
> just clears then appends.  Append/clear is a cleaner API design in
> general imo, precisely because you don't have to worry about colliding
> with previous activity by default.  A set/clear pair means that you
> have to explicitly check for existing data and handle it in a way that
> isn't completely trivial.

I am not saying remove append - I am saying that just also have set,
with the semantics that if you use set, its equivalent to clear;append

> Attempting to relegate same-name params to second-tier status isn't a
> good idea.  It's very useful for far more than the "old services that
> are also accessed via basic HTML forms" that you stated earlier.

I am not sure about that - I think a modern API design would be to
just send multiple values as an array (maybe CSV or TSV). Consider how
JSON values are encoded - do you have multiple values to denote
arrays? neither is this the case in XML (afaik). This semantic of
multiple yet different values for the same parameter is just
confusing, and as you said a mess for server side. I am less
optimistic than you are that it will be fixed.


> ~TJ
Received on Saturday, 25 September 2010 03:36:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC