FLUORINE is a system-level service providing access on each node, to each network interface on the node (be it an IPv4, IPv6, X.25, serial, etc. interface). Something very similar to BSD sockets is implemented by these interface entities, allowing ARGON systems to interact with the network directly.

FLUORINE also includes adapters to implement clients and servers for HTTP, ONC RPC, CORBA/IIOP, SNMP, FTP, DNS, TLS, SMTP, and so on. A database stored within the node entity is used by the FLUORINE module to find a list of TCP sockets and other such listener resources to bind to, whereupon it will perform a service similar to UNIX inetd, accepting requests and then passing them to the nominated entities to handle, in much the same manner as the MERCURY server side. Clients are written by accessing the gateway namespaces defined below.

FLUORINE will also provide CARBON gateway namespaces that gateway onto Internet protocols, via the IP interfaces available on the local node. This namespace will return references to entities which use personas to provide a gateway to Internet resources - the persona field containing a URI. For mailto: URIs, it will present an IODINE person interface, while anything that returns data (http:, ftp:, data:, gopher:, etc) can fake appropriate document entity types; at the most basic level they can present an interface to the data as a byte stream - but given MIME information, it will be possible to recognise text, images, HTML documents, and so on and convert them into appropriate IRON objects. These virtual entities will also provide interfaces to attempt XML-RPC and SOAP on URLs, and to perform plain old POSTs. We can also gateway to personal information systems such as FOAF and GoNumber; foaf:8b3ce83384145fe1187db8ef60c007efd7fae461/http://www.snell-pym.org.uk/alaric/alaric-foaf.xml and GoNumber:1337 would both return EIDs that provide IODINE person interfaces with lots of useful metadata and access protocols.

Here is a full list of gateways I would like to implement, in approximate priority order:

tcp:
tls:
These provide a gateway to straight TCP and TLS-encrypted TCP connections, respectively. The result is a virtual entity providing an octet-pipe interface, with extensions for TCP urgent bytes and whatever else is required for TLS. It should also support the object-push interface which, when given an octet string, opens a connection, sends the octet string, then closes it.
udp:
This provides a virtual interface supporting an object-push interface that only accepts octet strings, which are then sent via UDP to the destination. An alternative UDP-specific interface is available to send packets and wait for replies.
http:
https:
These gateway to HTTP and, indirectly, to services built directly on top of HTTP. The value of an HTTP URL is the result of performing a GET upon it, and using the FLUORINE MIME to IRON mapping. However, it also provides a virtual entity that can be used to directly access the HTTP protocol to GET, PUT, POST, and so on. Also, the object push protocol can be used to perform a PUT operation, after IRON to MIME mapping.
mailto:
This provides an interface to an SMTP email address. The resulting virtual entity will provide the object push protocol, converting the object into a MIME content part and then attempting to construct From: and Subject: headers from the object metadata (and, if failing to find a from address, looking to see if CARBON can be used to obtain an Internet email address for the entity invoking the push interface, as a User Agent might have; and failing that, resorting to something like argon@local hostname)
data:
This little gem is unlikely to be directly useful in ARGON, but it is sometimes used in HTML, and should be trivial to implement. Defined in rfc2397, it contains a base64-encoded MIME object. Our gateway can resolve the name to the IRON object that results from applying this to the FLUORINE MIME->IRON mapping system.
soap:
xml-rpc:
These provide interfaces to SOAP and XML-RPC by taking an embedded URL pointing to a WSDL file, or whatever XML-RPC's equivelant is. Using that information, a virtual entity is returned which then provides a direct mapping of the Web service into MERCURY interfaces. At the back end, it may use HTTP or BEEP to actually invoke the Web services, or other protocols in future.
go:
This gateway provides an interface to the Common Name Resolution Protocol, as defined in RFCs 3367 and 3368. This will generally resolve to a bunch of metadata to reveal as CARBON knowledge, plus a gateway onto the underlying URL returned by the name resolution server.
ldap:
This gateway provides an interface to the X.500 directory. The result will be a lot of CARBON knowledge generated from the referenced object.
ipp:
This gateway provides access to the Internet Printing Protocol, via the URL scheme defined in rfc3510. I need to look into this more, but I think the resulting directory node can provide a standardised ARGON printer interface - with management functions, metadata about the printer's capability, and CARBON subnodes listing current print jobs, and supporting the object push interface to submit print jobs.
sms:
tel:
fax:
modem:
These gateways, using the URL syntax defined in rfc2806, provide access to telephone networks by returning an appropriate IRON telephone number object. However, on clusters that have appropriate hardware, the result may also be an entity that provides a voice communication interface, an object push interface, or an octet stream interface, respectively.
rdf:

This gateway gathers RDF statements from a source URL specified in the name, then uses them to obtain information about a given object. This is then converted into CARBON statements and made available as statements about the name itself. Where possible - eg, a FOAF person object with an email address - it will also provide a virtual entity with appropriate gateway interfaces (in that case, an object push interface which maps to SMTP email, as per the mailto: gateway). Linked resources (foaf:homepage, foaf:weblog, etc) can be modelled by making the result be a directory node, with the linked resources as subnodes.

The mapping system will need pre-programmed knowledge of various RDF vocabularies in order to perform the best mapping possible. Any unsupported mappings should be wrapped and still made available, so that applications designed to operate on RDF directly can still access them.

Eg, my FOAF can be used to represent me with a name of the form:

rdf:http://www.snell-pym.org.uk/alaric/alaric-foaf.xml#abs

This causes the system to open the given RDF file, then extract statements about the resource with rdf:nodeID=abs and map them into statements about the CARBON name itself. I presume we could also allow an arbitrary URI on the right hand side of the # in order to extract statements about things that have URIs but no rdf:nodeID; I need to check up a bit more on the semantics of RDF.

news:
nntp:
imap:
pop:
ftp:
tftp:
nfs:
smb:
These provide gateways to file transfer or access protocols. They should appear to be CARBON directory nodes, with the remote filesystem tree appearing as an extension of the CARBON directory beneath them. The actual files should then be mapped, using the FLUORINE MIME mapping, to appropriate IRON objects where possible (falling back to an octet-string representation), while also providing a virtual entity that supports the object push protocol to overwrite the file (or, when called on a directory node, to create a new file in the directory) and a POSIX-style file access protocol (where one opens a connection to the file, then may seek and read and write, then close it). The ones designed for accessing email - NNTP, IMAP and POP - can provide the message body as a value unless it is a multipart, in which case it can be a directory node with the MIME tree replicated. Message and content-part headers will be mapped to the metadata in the resulting directory.
telnet:
As per rfc1738 - provide a proxy virtual-entity with a user interface (providing vt100 emulation) and an octet-pipe interface, with extensions for telnet options, and the object-push interface which, when given an octet string, opens the connection, sends the string, and closes it.
ssh:
Similar to telnet:, except opening an ssh connection. Because we need to authenticate to the server explicitly, there will need to be a custom API to specify a password or keypair for authentication, before we then get an octet stream interface. However, it may be worth defining a per-cluster database of SSH client authorisation information, along with ACLs for each entry, so that when an entity attempts an SSH connection the system just looks in this (protected) table to see what the entity is allowed to connect as, if anything, and then handles the connection. In which case, the ssh: gateway could provide a raw octet stream and object push interface, similar to the telnet: gateway. Either way, the gateway should also offer a user interface allowing interactive logins.
scp:
This gateway performs file transfers atop the ssh protocol. It has the same authentication issues as the ssh: gateway, but instead of offering an octet stream connection, it instead provides a directory structure, like the ftp: and similar gateways.

FLUORINE will be crucial to the success of ARGON. Without it, ARGON is just another wierd system incompatible with the mainstream, and thus doomed to fail outside of a few tiny niches. But with it, ARGON becomes an easy way to provide network services on top of a powerful, easily managed, distributed cluster architecture that can extend from large machine-room servers, through the desktop, down to small embedded systems.