WORK IN PROGRESS
IODINE is a list of standard entity interfaces, defined as MERCURY interfaces and CARBON tuples that the entity is expected to provide.
MERCURY defines a protocol by which an entity may publish which MERCURY interfaces are provided on which interface numbers ([</argon/mercury/entity>: EID; provides: interface symbol on: endpoint number]).
CARBON defines lots of useful tuple schemas for information about objects, many of which are useful for talking about entities.
Short name, long names in different languages, description in different languages, etc. Look at Dublin Core for inspiration.
Also, CARBON defines the containment/link relationship used to form the CARBON namespace used for IRON symbols (based around short names).
/argon/iodine/push: Object Push
Here, have an object, represented as a CARBON knowledge bundle full of statements about the object (which is identified as object at the default namespace binding when the bundle is interpreted)!
Usable for all sorts of sending tasks. To a user agent, it can be used to send emails, workflow tasks, appointment invitations, etc. It's 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 already 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.
/argon/iodine/directory: CARBON directory
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.
Provides CARBON directory links in the public CARBON data.
/argon/iodine/container: Storage Container
Offers the user the ability to create an entity, given a template.
Provides CARBON directory links to contained entities.
/argon/iodine/document: Editable document
This interface is for editing document entities, whose primary function is to publish some static data, for example CHROME source code or general CARBON reference data.
The document entity doesn't directly publish the data in its CARBON metadata, but provides personas whose CARBON metadata is each a version of what is published. The document entity itself provides links to the latest release and other useful information. In essence, a document entity provides a version control system suitable for maintaining a published artefact:
* Branches and merges
* Pull requests
* Code review process for pull requests
* Tagging a release (only "release" versions are listed on the "front page")
* Ticket tracking, and linking tickets to commits
* The ability to clone a document entity, and then to push pull requests back to the origin
* Managing the "project metadata" also exposed from the document entity; this covers the functions of project home page and project wiki for internal documentation that shouldn't be versioned along with the source (THAT stuff can actually live in with the source). This itself is a "document" in its own right, so is modelled as a chain of versions inside the document entity itself - but with a separate root commit, similar to how github pages work. The project metadata doesn't have releases and code reviews, though.
Each actual version (release or not) gets a persona that exposes that data via CARBON, plus a small metadata statement marking it as a version of something, with a link to the document entity itself and to all parent/child versions, and metadata declaring it as a release or not.
A special persona reflects the "latest version" of each branch, by issuing a redirection to the actual persona for that version, too.
/argon/iodine/entity: Entity Administration
Edit ACLs, delete entity, directly edit TUNGSTEN state, debug mode, create new entities.
/argon/iodine/physical: Physical object
Location information, and images (from pictures to 3D models) of its physical manifestation.