Interoperability and Demesnes (by alaric)
Obviously, this has some relevance to my dreams of implementing ARGON. The whole thrust behind ARGON has been to redesign things from scratch in a lovely way rather than bothering about the economic arguments for remaining compatible with existing stuff so I can re-use it. But I still want to interoperate with the rest of the world, for one good reason: it's a desirable feature.
Unsurprisingly, as you may have guessed, I plan to make the world of ARGON a demesne. One big one covering all ARGON clusters on the planet, naturally, since they can intercommunicate with MERCURY. But since the underlying data model within ARGON is the union of IRON, TUNGSTEN, and CARBON, rather than the traditional "named byte vectors organised into a tree on disk, and MIME-wrapped byte vectors for communication" model of the rest of the world, we're kind of forced into a demesne model.
Which is what FLUORINE is for. It's the demesne border. FLUORINE contains mappings between the world of files and the world of CARBON; and it contains the mappings from the world of HTTP and SMTP to CARBON, too. Thanks to the rich semantics of CARBON and the unbounded power of how it's implemented over MERCURY, it's possible to gateway seamlessly, making standard filesystems and network resources appear as part of the CARBON global directory. Ok, I say seamless - as seamless as is possible; it'll still sometimes be hard to tell what character encoding a text file uses, so there will still be problems, but at least there's a single point we can place measures to reduce those problems - and there will be no problems when communicating within the ARGON demesne...
Sat 10th May 2008 9:17 pm 
Subscribe