Re: MUST a collection be returned as an Atom feed?

[Aristotle Pagaltzis <pagaltzis@xxxxxx>]

* Jan Algermissen <algermissen1971@xxxxxxx> [2010-01-02 21:20]:
> >* Jan Algermissen <algermissen1971@xxxxxxx> [2009-12-28 18:10]:
> >>Given it is a MUST requirement, it can be said that clients
> >>can make the assumption to receive an Atom feed document as
> >>the response to a GET request to an AtomPub collection
> >>resource. Yes?
> >
> >No.
> >
> >The server is free to return anything it wants.
>
> Easy to say that - but the issue is really: If a server tells
> a client it is an RFC 5023 compliant server (by sending the
> client an application/atomsrv+xml service document) the client
> will expect to receive an Atom feed as a response to a GET on
> a collection (based on the contract defined by RFC 5023).

That’s what I addressed in the following part of my message that
you didn’t respond to:

> > If the server does not return an Atom Feed Document,
> > then the client and the server cannot interoperate.
> >
> > More correctly, they cannot interoperate based on the rules
> > of AtomPub. Maybe they can still interoperate based on some
> > other protocol – that’s fine. But they cannot interoperate on
> > the basis of compliance to RFC 5023: RFC 5023 has nothing to
> > say about such an interaction.

But anyway:

> In fact, you cannot code anything useful without such an
> assumption in an M2M scenario.
>
> When the server returns a 5xx and hundreds of business
> transactions are lost - who is liable?

If the kernel returns EINTR when you try to open a file, and you
don’t check for an error and hundreds of records are lost, who is
liable?

The same person in both cases – whoever wrote the client.

> It makes no sense to answer to this that the server is not (or
> in fact can *never* be) liable because no client may make any
> such assumption. You can write blog indexing crawlers based on
> that but not business systems where the client necessarily!
> follows its own sequence of goals.

Do you write business systems that don’t check the return value
of `open`?

> See it this way: How does the service owner know, in what way
> the service can evolve without breaking the interactions that
> the service enables in the first place. You position would be
> that it is perfectly ok for the service developer to abandon
> Atom feeds completely and send some nes stuff instead as long
> as a proper HTTP error code is being sent.

No, that’s not what I’m saying. I said explicitly that if the
server is to conform to AtomPub, it MUST send an Atom feed. If
the server does not send an Atom feed, then necessarily it does
not conform to AtomPub.

Now, the client shouldn’t blindly expect the server to conform to
AtomPub just because it’s in the business contract or because the
server sent a service document, any more than it should blindly
expect `open` to always succeed.

But you are confusing two levels of agreement here: agreement on
what RFC 5023 means, and agreement about an obligation to comply
to RFC 5023.

Obviously the latter cannot be achieved without the former, but
they are still distinct levels of agreement. RFC 5023 is limited
to the former in scope. You will not find answers to the latter
in it.

> What if there is an SLA liability fee pertaining to the
> availability of the reports?

That’s the SLA’s job to define, not RFC 5023’s.

RFC 5023 can only set the parameters for compliance to AtomPub.

If you agree on a contractual obligation for compliance to
AtomPub, that’s your business decision, it’s not a policy within
the scope of RFC 5023.

> Thats nonsense because nobody can implement a client without an
> expectation what might be coming back.

Well, if you can’t open a file, or committing a database
transaction produces an error, or memory allocation fails, then
likely the code is at a point where the error cannot be handled
gracefully and all it can do is die screaming.

> Saying that the client should be able to handle 406es by
> calling the dev team to quickly adapt the client to the changed
> server would not be agreed upon by any client owner.

Is this supposed to be some sort of argument?

> No matter how loose coupled HTTP or AtomPub is - the contract
> exists in some form anyway and can be broken (including 406es).
> If it breaks, someone is responsible and it is pretty sure that
> putting the responsibility on the client makes no economic
> sense (in M2M scenarios).

Of course.

See above.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>