also the logical interface to use for printing; object push something
to the printer. A CARBON directory might accept an Object Push (from
somebody with sufficient rights) by creating a directed link if an
entity ID is pushed. Entities containing user-editable information
might accept general bundle pushes containing no explicit object (eg,
no statements about the object at the default namespace prefix), but
full of metadata about other objects, too.

This is the standard way to send an asynchronous notification of
anything in ARGON - so although object push is a MERCURY interface to
directly invoke the target entity, perhaps object push needs elevating
to a special status in MERCURY so that persistent queues can be used
under the hood. This is the situation where Apache Kafka or RabbitMQ
and friends might be used in a legacy system. A lot of the power of a
standard MoM system is already provided by ARGON; incoming MERCURY
requests will <i>already</i> be distributed reliably across the
cluster, but asynchronous queueing is something extra. We can have an
"asynchronous send" operation in MERCURY which Object Push is
implemented in terms of, but that would also be available to other
protocols - but should they not just be standard object pushes as
well? I feel that an entity should have a single push endpoint that
dispatches on the type of the pushed object, rather than lots of
different kinds of push. Maybe having other push endpoints would be
acceptable for cases like sending out updates to a watched value, or
streaming media frames, over a MERCURY connection rather than the main
public interface of an entity...

One interesting issue is that of message coalescing in the MERCURY
implementation itself (eg, within queues). This can consist of
bringing together messages that all affect the same bit of final data
(based on a bucketing function supplied by the endpoint) so they can
be processed more efficiently in terms of their load on the storage
system, and of allowing messages that supercede others to cause the
superceded message to be deleted in transit (based on a second
bucketing function to define the equivalence classes, plus an ordering
function between messages).

As both involve bucketing functions, they could be implemented within
the target cluster when it queues incoming messages for execution;
performing coalescing when messages are queued in the origin cluster
is possible, but requires the origin cluster to run arbitrary
bucketing functions supplied by the destination as part of MERCURY
sending, which might be a bit of a cheeky request.

<h1><tt>/argon/iodine/directory</tt>: CARBON directory</h1>

A user-manageable CARBON directory node, as opposed to one that
generates the directory links programmatically.

Link to entity. Edit list of linked entities and their local metadata.