[ Home | Contents | Search | Post | Reply | Next | Previous | Up ]
From: Pavel.Binko@cern.ch
Date: 10/19/99
Time: 2:45:12 PM
Remote Name: 137.138.115.180
FYI
--
Pavel
Dirk Duellmann wrote:
Dear all,
as promised on the last RD45 workshop, we will starting from today
regularly make snapshots of the espresso POM prototype available through
AFS (you'll find dated tar files in file:/afs/cern.ch/rd45/espresso ).
The aim of these snapshots is mainly to start the discussion about
design issues and to get more input from you about requirements for
(not only) alternative POM implementations.
Since this first snapshot is still in an early prototype stage and not
yet of any real use to end users , the idea is to to keep the discussion
for the moment in the group of ODBMS experts.
For this purpose we have setup a new mailing list
( mailto:rd45-espresso-dl@listbox.cern.ch ) and you are apparently on
it.
If you feel, you should not be on this list or somebody else
should be, please let me know.
So please take a look at the attached README file and take a moment
to checkout the examples programs of the current prototype and let
us know what you think.
Cheers, Dirk
About this Espresso Snapshot
----------------------------
This is the first snapshot of espresso, an attempt to
prototype a scalable Open Source persistent object manager.
The current snapshot provides still very limited functionality
and is NOT meant as release suitable for end users. Please do not
expect a stable product! Espresso is currently neither stable
nor a product.
So, why should I even care to look at it?
-----------------------------------------
On the other hand this snapshot already shows some of the
basic design ideas and allows to prototype various aspects
of POM implementations.
The intention of making this snapshot public is really to
start the discussion among the various odbms experts about
the general architecture of the package, its main feature and
implementation issues.
BTW: In this snapshot we would like to mainly concentrate on
the core modules (storage manager, schema manager and c++ binding).
Lockserver and page server sources are provided as well but not
compiled in by default.
Package Architecture
--------------------
- domain decomposition
sm - raw storage manager
raw language independent storage of structured data
sh - schema manager
management of the type descriptions
cp - c++ binding
transparent data access to c++ objects and collections
ls - lockserver
server implementing a centralized lock table (& its client
interface)
ps - page server
multi threaded server implementing abstract file IO on
remote machines
com - global interfaces and general utilities
OS abstraction, debugging support, application framework for
espresso tools,
- dependencies between the domains
Required Features?
------------------
Please let us know about your personal hit list of
required / desired / useless POM features.
My personal `required/desired' list contains right now:
- scalability for address space and locking
- transparent cross file navigation through templated smart pointers
- transaction based I/O
- I/O on demand
- crash recovery
- full C++ support including user defined persistent templates
- ODMG compliant API including support for transient objects and
activation/deactivation
- builtin support for user provided converter classes
- light weight allocation of objects which are likely to be deleted
Implementation Issues
---------------------
- Core system
- is there a better way to extract the needed schema information using
a post-processor?
- which extensions to the ODMG binding are required ? which are
acceptable?
- is separating the transient collections from their persistent
store (like in the current design) useful?
- { your topic here }
- Lock Server
- one per domain? one per federation?
- Data Server
- on physical page level (as in the current design) or on
logical page level? on object level?
Of course, any kind of contribution is welcome.
How to get started?
-------------------
The best start is probably to browse through the
example and test programs to see what is already there.
- $(ESPRESSO_DIR)/examples/populateDb
- store and retrive a simple event object model
- data access using the ODMG C++ binding
- transparent navigation between the different persistent objects.
- create and retrieve named event collections
- $(ESPRESSO_DIR)/examples/histo1D
- store and retrieve htl histograms
- $(ESPRESSO_DIR)/sm/tests/store
- exercise the raw storage manager
- dump persistent objects
- benchmark the store and retrieve performance
- $(ESPRESSO_DIR)/cp/test/odmgtest
- schema
- dump persistent objects
- benchmark the store and retrieve performance
Just build and run the examples and try
to modify them. Take a look at $(ESPRESSO_DIR)/INSTALL
for more details on how to install and build the
espresso libs and examples from the tar file.
NOTE: We will add some more realistic examples and test
soon, but I guess what is provided is sufficient to get
some first impression. If you have some code which could
serve as example please let us know.
To get a more detailed overview about espresso you may
want to browse through the reference manual in the directory
$ESPRESSO_DIR/doc/reference-manual . There are the usual
html and hyperlinked PDF versions of all class decriptions.
Supported Platforms
-------------------
So far only Linux (RH 5.1 - RH6.0) and egcs (1.1.1 - 2.95.1)
Solaris and NT could follow next (if there is sufficient interest).
How can I contribute?
---------------------
Any comments, suggestions about espresso may be directed either
to our public discussion list
rd45-espresso-dl@listbox.cern.ch
or directly to the developers
rd45-espresso-editors@listbox.cern.ch
Please also let us know in which direction you would like to
see espresso going in the next time (if anywhere :-)