[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Meaning of PUT
On 6/14/06, Joe Gregorio <joe.gregorio@xxxxxxxxx> wrote:
On 6/14/06, James M Snell <jasnell@xxxxxxxxx> wrote:
> So as an implementor who is mapping APP and Atom onto a pre-existing
> relational data model, I would have to scan every entry in every request
> for any elements and attributes my implementation is incapable of
> storing rather than just looking for the bits and pieces I do understand
> and am capable of handling, effectively rendering Atom's Must-Ignore
> extension semantics absolutely useless to me as a server developer and
> consuming additional server resources for what reason again?
Exactly, this is what I meant when I said that this made
APP a must-understand protocol.
Must-store and must-understand are different things, at least to me.
I can store XML content w/out understanding it's semantic significance
to the client. An APP store might support and store
client-namespaced data w/out understanding its meaning... but if it
doesn't do that (store), I feel obligated to let the client know that.
There's a difference between a very permissive APP service (ex, a
generic Atom aggregator) and a more narrowly constrained one (ex. a
Calendar service that expects entries w/ specific content
constraints), but in both cases, when they accept an entry its
I don't understand James relational DB-exposed-as-Atom example. If I
try to set a column that a DB can't match to the underlying schema
using SQL, I get an error. Why woudn't I expect the same if I did so
via an Atom mapping over SQL relational data?
Wouldn't you parse the input data for the bits you do persist (to
store them) and isn't it possible to recognize that there are
exceptions? Is there really extra work there?
Honestly, I'm not religious about this issue, but I'd feel better if
someone gave me one real world use case that I could get my arms