caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Matt Gushee <mgushee@havenrock.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Cross-platform DBM equivalent?
Date: Thu, 26 Dec 2002 03:05:38 -0700	[thread overview]
Message-ID: <20021226100537.GD1071@swordfish> (raw)
In-Reply-To: <3E0AC045.3080307@baretta.com>

On Thu, Dec 26, 2002 at 09:39:33AM +0100, Alessandro Baretta wrote:
> 
> >I am developing an application that needs fast access to persistent
> >configuration data, and I thought that DBM might be a good way to
> >provide that functionality ...
> 
> Are you sure you need DBM to reed in a config file? Would 
> the Scanf module not serve your purpose?

Am I sure? No, I'm not sure of much of anything at the moment; as I
said, the project is at a very early stage. But I'm concerned about not
so much reading a config file as *accessing configuration data at
runtime*.

Let me try to clarify this a little. As I said, this is a web
application; its purpose is to generate on-the-fly graphs (bar graphs,
line graphs, pie charts, etc.) of numerical data (which will probably
come from a relational database in most cases). And I intend it 
eventually to be usable by not-very-technical people.

The way this is supposed to work is that when a client requests a
certain URL representing a generated image, my application obtains a 
mapping from the requested URL to the process that generates the 
image. Generally speaking, the process will consist of querying a data
source and passing the results to a library function that generates a
graphic.

Anyway, the configuration data my question referred to is the mapping of
URLs to processes. The URLs are defined by the user, and there is
potentially a large set of them. But for each request, the HTTP handler
needs to discover how to process one of those many URLs. So it's a
matter of fast random access to the configuration data, and DBM seems to
me a pretty good way to achieve that.

(I should also note that at this prototype stage, I am planning to
deploy the handler as a simple CGI program. I expect that for production
releases it would be preferable to have a long-running process that
talks to the web server through the JServ protocol or some such thing;
in that case it would probably be best to read in the URL map at startup
and just keep it in memory. But I'm trying to achieve visible results as
soon as possible, so I'd rather keep the handler component simple for
the moment).

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)
-------------------
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


  reply	other threads:[~2002-12-26 10:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-26  7:17 Matt Gushee
2002-12-26  8:39 ` Alessandro Baretta
2002-12-26 10:05   ` Matt Gushee [this message]
2002-12-26 16:50     ` Pierre Weis
2002-12-26 17:03       ` Joshua D. Guttman
2002-12-27 13:07         ` Pierre Weis
2002-12-26 17:08       ` David Brown
2002-12-26 18:23       ` Stefano Zacchiroli
2002-12-27 13:11         ` Pierre Weis
2003-01-12 10:13           ` Sven Luther
2002-12-26 19:20       ` Dmitry Bely
2002-12-27 13:19         ` Pierre Weis
2002-12-27 18:03           ` brogoff
2002-12-27  7:21       ` Matt Gushee
2002-12-26 20:00 ` Yaron M. Minsky
2003-01-02 10:03 ` Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021226100537.GD1071@swordfish \
    --to=mgushee@havenrock.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).