From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA25359; Sun, 13 Jul 2003 11:55:12 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA05394 for ; Sun, 13 Jul 2003 11:55:11 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h6D9t5f20221 for ; Sun, 13 Jul 2003 11:55:05 +0200 (MET DST) Received: from ozemail.com.au (203-219-67-160-syd-ts23-2600.tpgi.com.au [203.219.67.160]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h6D9svI08659; Sun, 13 Jul 2003 19:54:58 +1000 Message-ID: <3F112C70.6070300@ozemail.com.au> Date: Sun, 13 Jul 2003 19:54:56 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Basile STARYNKEVITCH CC: caml-list@inria.fr Subject: Re: [Caml-list] adding data persistency in Ocaml... References: <16141.20207.531689.793421@hector.lesours> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; ozemail:01 caml-list:01 persistency:01 basile:01 marshalling:01 opaque:01 persist:01 bytecodes:01 reloaded:01 dynamically:01 binaries:01 nativecode:01 toxteth:01 glebe:01 2037,:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Basile STARYNKEVITCH wrote: > If you have wishes or ideas on how to do it, potential applications in > need of it (CGIs are obvious candidates, but there are other > interested applications) or pitfalls to avoid, or relevant literature, > please feel free to discuss them on the list (or to send it to me if > you feel it is not of general interest). I am using a basic kind of persistency in my Ocaml program Felix which is a C++ code generator. I do it by Marshalling the data (which is all simple term structure) along with a time-stamp/version info. ------------------------------------ Issue #1: At present, the format is abstract/opaque. This means it cannot be read by an external program. -------------------------------------- Issue #2: my test for version is overly aggressive. I'd like to be able to be able to read the data even if it's in an old format, provided the newer data structures used are compatible in some way. Note I'm not talking about the version of "Marshal" used in Ocaml, but my own data structure. For example some polymorphic variants might be extended to add new terms, without invalidating the old data. > Obviously the main problem I identified today is to be able to persist > (and share) data with a slight change in the program using it - That's my issue #2. I extend it from 'new program with same old data structures' to 'new data structures which are still compatible with old ones'. You might even consider that one may wish to *convert* the old data structures with a user defined conversion routine in case the old data is compatible in-the-abstract, but not compatible concretely. -------------------------------------- Issue #3: persistent functions. This is a nasty one. In theory, some bytecodes can be written out and reloaded. For native code compilation, we could write out binary and dynamically link it -- this would require re-entrancy and some other constraints (such as having a restricted environment such as 'Pervasives' and nothing else). Clearly, a programmer can invent an encoding of an algorithm, write an interpreter, then load the bytecodes dynamically. It would be useful perhaps if a native code program could be linked with the core bytecode interpreter, which could run bytecodes and/or saved binaries. I think this is both a nasty problem and also messy due to the bytecode/nativecode mixed implementation. ------------------------------------ Issue #4: views This is a kind of extension where you don't load the saved data, but create a view of it. The main reason not to do this 'in memory' is a security thing, but other reasons such as 'the SQL data base is too big' come to mind :-) For Felix, I may want to link parts of a library, without loading the whole library, which implies some kind of searching of the persistent data. -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners