BeesAndAnts

From W3C Wiki
Revision as of 14:39, 13 December 2005 by (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are two ways to communicate:

  1. Like Bees (with
the honeybee dance), you can transmit your knowledge
in an ephemeral way, available only to the immediate
audience.  This is message passing.   E-mail tends to be like this.
  1. Like ants (with their scent trails), you can change the environment in a
persistent way (called stigmergy), making your knowledge available to those
who come along later.  This is shared memory.  Wikis tend to be like this, as does the Web in general.
(See also: CommunityWiki:DocumentsVsMessages)

This strongly relates to DeltaView but is not exactly the same thing:

  • the minimal message is a delta
  • extra information in a message can be seen as extra context for the delta
 (as in "context diffs" which provide some robustness for rearranging deltas).

Publish/Subscribe is the idea of turning every delta into a message.

Archiving is the idea of storing every message, making it persistent in an immutable state. Some archives (as from Pub/Sub) are DeltaView's and can be summed to mirror some original system. See RDFAccessProtocol.


Which is the Web? If the Web only did GET, it would very much be a shared memory system. But POST is definitely a message passing construct, as it permits information about new pieces of shared memory to be disseminated. The Web is like some new uber-insect which sends information that identifies scent trails. -- MarkBaker

I don't agree that POST breaks the shared-memory view. There are two ways of thinking about POST which fit with shared-memory:

  1. POST creates a new "nearby" page. This is what TimBL originally had in mind. So
POST is like shmat/mmap, giving you a new area of shared memory.  It's not a memory-read or 
memory-write operation, but it's still part of the shared memory model.
  1. POST adds information to the location posted-to. This requires thinking of shared-memory locations as more like
mutable strings or files than fixed spans of memory.

Existing uses of POST can be viewed as either or both of these, even if that's not what the designers had in mind. For instance, the POST to buy a book at amazon does modify persistent state, creating a new database record in their system. It would be very nice if they told us the URI of that record (puting it on the web), but their failure to expose the new shared-memory bits doesn't mean they don't exist. <shrug>

Rather than asking "Which is the Web?" maybe we can ask the more practical questions: "When Should Systems Make Messages Persistent?" (whenever you can afford to keep them around!) and "When Should State Changes Be Sent Out As Messages?" (whenever someone subscribes!) Does any good come of drawing a line around around "The Web"?

  -- sandro

I think you misunderstood, because I agree with what you wrote. I wasn't saying that POST broke anything, only that it can be used to augment the shared memory model with some of the benefits of message passing. The particular use of POST I was talking about wasn't creating new areas of shared memory (though that is a very useful shared-memory-centric use of POST), but instead just passing URIs around in POST content, so as to spread information about other areas of shared memory around. --MarkBaker