How do you POST to a "document"?

> I still don't understand how that system explains a POST
> of a message to an HTTP-to-SMS gateway that is identified by
> an http URI.  I'd like to understand that.

My first experiences with programming were on systems where the only
communication path was shared storage.  One was a multiuser system
with no interprocess communication method; so I wrote a chat system
which used shared files as message queues.  The other was a
microcomputer which used entirely memory-mapped I/O.  To display
something on the screen, you would change certain bytes in memory; the
hardware used those bytes to guide the screen display.  To find out
what keys were pressed, you looked at a byte in which the bits
corresponded to wires on the keyboard matrix.  (I think this was
essentially true of all 6502-based systems, since it lacked the "in"
and "out" opcodes of the 8080 and its decendants.  It was possible to
get interupts, eg from the keyboard, but the data came through shared
memory.)

To indulge a little more history: some bytes were tied to voltages on
external pins; when you cabled them together the byte vales on
multiple machines where related: all machines saw the logical-and of
the values each machine had stored, because a 0-bit meant
tie-to-ground and a 1-bit meant apply-a-few-milliamps-to-raising-to-+5V.  
Those few milliamps could not overcome the tie-to-ground, so 0 and 1
was 0.  (Or maybe they put the resistor at the other end, and I have
it backwards; I'm not really a hardware guy.)  So it was a little
tricky and slow, but you could build multiuser, multisystem apps
through a couple bits in memory space.
	
I suppose these experiences got me used to thinking about
communicating through shared storage, even when I realized that it
wasn't always the ideal approach.  But sometimes it's great.  I would
say ORACLE's business is in building applications which both store and
communicate using a shared database.  The LINDA/JavaSpaces approach
takes a different approach in making shared-storage apps efficient.
Lynch's Distributed Algorithms book [1] spends 215 pages on
asychronous shared memory algorithms, and a chapter on transformations
between the Shared Memory Model and what she calls the Network Model
(basically message-passing systems).

So I think of the web as mediated shared memory.  Each web address
(URI) points to a storage location.  GET means to read the contents of
a location, PUT means to store replacement contents in a location.
Sometimes I think of the locations as individual whiteboards, bulletin
boards, shelves, slots, or parts of a landscape where a signboard
could be placed.

The situation is complicated by the open network.  I can't actually
see the whiteboard; I can only talk on the phone to the person [ er,
computer] in charge of the whiteboard.  That person may be cooperative
and tell me what's on the whiteboard; he may even honor a PUT request
from me.  He may also have several versions of the board in different
languages, which he can read to me over the phone based on the
languages and formats I asked for.  He can also be lying on a beach in
the Virgin Islands, with no real whiteboard at all, and I can't tell
the difference.  (Of course in the Virgin Islands, a weather report
whiteboard might as well be carved granite, since it's always 80'F.)
He may act differently based on caller-ID [IP address], but that's
generally frowned upon.

HEAD means tell me about what's on the board, without actually reading
it.  DELETE means throw the board away.

POST could mean a few different things.  It could mean "please obtain
a new whiteboard and put this content on it."  It could mean "please
add this content to the current whiteboard".  It could just mean
"here's something I want to tell you."

I would probably be happy if instead of POST we had CREATE, APPEND,
and MESSAGE (but I'm not holding my breath).  I think web services
designers would do well to use POST as CREATE and APPEND more often
than as MESSAGE.  When I POST to buy a book, I'd like that to CREATE a
lasting page of information about the purchase transaction.   

Which brings us to your question of POST to SMS.  This is like my
using shared files to build a chat system.  Why are they using HTTP
POST instead of sending a reliable IP datagram?  Because that's what
the system provides, I guess.  Maybe it's a bit of a perversion...,
but I happen to like that particular perversion, because it means we
can attach more data.  Turning a message into a web page allows us to
refer to it later.  

If the POST is seen as CREATE, then they've made a web page I can use
later to review my message and its status.  Maybe the POST response
says "Message Sent; for a record of this message see [link to
newly-created page]."  If the information on that page is just the
text it's not terribly useful, but as it includes more and more data
and links to data, it starts to make a lot of sense as a web page.
It's a bit like this SMTP e-mail I'm writing which will end up on a
mail.w3.org web page.  Maybe this is a very special (SMS) message, and
people are going to start to point to it for historical interest;
maybe no will ever view it on the archives -- but it's nice to have
the option.  Maybe the page will have access-controlled links to other
messages from the same sender, other message to the same receiver, and
some sort of low-level delivery receipt (does SMS have that?).  If
it's possible to edit or retract a message because delivery has been
delayed, this page could provide access to that functionality.

So I want to send an SMS message.  I find a page, a web form, to help
me.  I fill it out, click SUBMIT, and my browser does a POST to a URI
given in the form.  Essentially, I'm handing the mediator/server
for that URI an index card and saying "Post This".  Maybe he puts it
on a new bulletin board (CREATE), maybe he puts it on the one for that
URI (APPEND); in either case he (or some co-worker of his, whom he
notifies) also sends the requested SMS message.   And hopefully they
continue to offer useful and interesting information on the web.

As a variation here, we could build HTTP-to-SMS where the HTTP server
knows nothing of the SMS machinery.  It receives the information and
puts it up on a new web page.  Meanwhile, an SMS agent notices the new
page, sends the appropriate SMS message, and also APPENDS that the
message has been delivered or whatever.  I don't know of current web
protocols which efficiently support "an SMS agent notices the new
page", but a variety of publish/subscribe, "push", tuplespace, etc,
approaches would work.  The advantage to this split is in modularity,
scalability, and abstraction.

But now I'm handwaving.  Are you nodding in understanding or scowling?

I've mentally run through this kind of scenario for coffee machines,
physical robots, cvsweb views, etc....   I'd be happy to write them
down (in executable code if necessary) if that would help.

Meanwhile, my explanation has been mostly metaphorical, obviously not
the right level for standards.  And I'm not saying this world view
should be or should have been in 2396 or 2616.  But I think some
conversation along these lines is essential to understanding how RDF
should really use URIs and also how Web Services can really benefit
from the design of the web.

My understanding of these issues is largely due to conversations with
TimBL, but of course my views are my own. 

> I am a little disappointed that Sandro introduces another set of terms
> that are just as open to disagreement.

I'm sorry I wasn't able to find better language in the timeframe I
needed to act.  (I'm still trying hard; I'm working on another reply
to your e-mail addressing some terminology/ontology issues.) That
particular document was aimed at the the RDF community (before RDF
Core WG went to Last Call), not the TAG.  I'm very sorry for the
places where I now see it probably misrepresents and/or disparages
your views, and I'm trying to think of how to express myself better
and correct that page.

   -- sandro

[1] http://theory.lcs.mit.edu/tds/distalgs.html
    http://www.amazon.com/exec/obidos/tg/detail/-/1558603484/qid=1043342659

Received on Thursday, 23 January 2003 13:35:02 UTC