Re: requests for clarification

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 25 Dec 2011, at 15:40, Anil Madhavapeddy wrote:

> On Thu, Dec 22, 2011 at 09:36:09AM +0000, Richard Mortier wrote:
>> 
>> imo it might ultimately be nice to try having a near-identical interface
>> between network and storage - kinda like sockets vs fds but type-safe.
>> i guess in such a case the orm would become more of a dynamically
>> reconfigurable un/marshalling stub generator service (cf.
>> <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7410> from
>> nemesis days) operating on some appropriate reader/writer interfaces.
>> perhaps with barriers to stop frp frobbing stuff on disk - an
>> interesting concept for the immutable datastore perhaps?
> 
> The ORM can support introducing barriers automatically into autogen I/O
> code, but the main challenge is pinning down how to delete values. There's
> no garbage collector on disk, so where does the 'gc root' come from?

or perhaps the data structures on disk need to support different invariants?

> Overall, I think OCaml has advanced quite a bit in the last few years from
> when we did the ORM. It now has first-class modules and GADTs (in trunk)
> that should make it easier to define an ORM without the need for so much
> code-generation. Id also like to integrate FRP into the way we persist
> values, so that one could (for example) have threads be activated when a
> variable on disk changes.  Thus, editing a config file would actually
> side-effect and cause stuff to trigger.

yes- that is exactly the example i was thinking of - some straightforward way 
to have the code that implements both archiving a versioned set of config files 
(the "immutable append-only store"), and that links the on-disk representation 
with the live in-memory (or indeed, distributed over-network) version(s).  

i do like the idea of having a config file edited outwith its owning 
application wake up the application to detect and respond to the change- which 
feels more like a network interaction than a normal storage interaction.
-- 
Cheers,

R.


This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.