Re: MGET and machine processing

>>> A SW agent should *not* have to examine the content returned
>>> to determine if it is what it asked for. Either the server
>>> understood what it meant (and the protocol is sufficiently
>>> precise to achieve that) and returned what the agent asked
>>> for, or it returns an error.
>> Sure, it's not ideal, and if HTTP had mandatory extensions we wouldn't
>> have this problem.  But it's by no means a big deal in this specific
>> case since you can just check if the media type that's returned is the
>> media type you asked for.  Suck it up! 8-)
> Er. Well, this is precisely what I meant earlier by "sloppy hacks".
> The amount of potential (or rather, likely) overhead to work around
> ambiguous behavior on the part of servers will be too costly in the
> long run. It's OK for a single system, but not for a global standard.
> Sorry, that just doesn't satisfy my expectations for a well engineered
> SW architecture, particularly given the far greater need for precision
> and reliability that the SW has over the Web in general.

We assume that Web and SW are unified/reaching their potential
when we simply follow
So log:semantics can easily result in an actual HTTP GET of
for instance
  eg:r1 eg:p1 eg:r2.
  eg:r2 eg:p2 eg:r3.
  eg:r3 eg:p3 eg:r1.
which is just an example of 3 statements about 3 resources
but which is not particularly connected to (and so MGET-able
from) one of those 3 resources.

Jos De Roo, AGFA

Received on Sunday, 23 November 2003 07:19:35 UTC