[Developers] new DataPack class: overview and benefits

[Helene Huck]

Hi all,

As data and positioning are strongly coupled in most of the cases, we
needed a way to carry them together throughout the code; in addition to
that, we identified that many elements holding data could be described
in a similar way, this is the aim of the new DataPack class. And even
more important : by adding these together we are able to share data in
such a way that the using object doesn't need to know what it is
handling, this then solves a lot of dependency problems.
Another purpose is to keep the memory management handling inside the
packets: all packs can report memory and destroy the content in the way
needed for that pack.

Let's take an example: the uiFlatViewer ( 2D Viewer ) can use all
FlatDataPack-s ( subclasses of DataPack  for flat data ) because these
are self-describing, and the viewer itself does not have to bother about
data management: the DataPack does it!
If you combine this with the example of the SeisTrcBufDataPack described
in Bert's previous post
( http://lists.opendtect.org/pipermail/developers/2007-August/000082.html )
it's quite easy to see how this is open to extension and still
straightforward to use.

Let's now see how to create, manage and use these DataPack-s:
A DataPack (="data packet") holds data+positioning and more that needs
to be shared (name, category of data...), the code can be found in
General/datapack.*
An ID is assigned to each new packet of data, the data pack ID is global
thus unique. These IDs are not stored, they are valid within each
opendTect run only.
To be able to manage and share the data we need a specific object, the
data pack manager (DataPackMgr). In fact, we chose to have separate
managers for all different types of data. Currently, we defined flat,
volume and surface (triangulated) data. It is possible to make a local
DataPack manager if you don't need to 'publish' your data. But in
general, you would want to use one of the standard DPM() or create your
own DPM() (i.e. still use the DPM() mechanism) - in that way, it will be
included in the Data Pack dump - yet another benefit.
 When you obtain the data for looking at it, you can choose to 'only
observe' or to obtain a reference whilst making sure the data is not
thrown away, this means you must release the data pack once you no
longer use it. You can find a good example of DataPack access with DMP
in src/PreStackProcessing/prestackprocessor.cc in Processor::prepareWork().
This way of packing data is quite easy to use and the unique ID coupled
with the global management tools make sure that data is not destroyed
unapropriately whereas it can be spread and used in various low level
classes which only have dependency to the DataPack itself.

This is it for the concept overview, to my mind this is aimed to be used
more and more in the future.

best regards,
Helene





-- 
-- Helene Huck
-- Geophysical software engineer
-- dGB Earth Sciences B.V.
-- Nijverheidstraat 11-2, 7511 JM Enschede, The Netherlands
-- mailto: helene.huck at dgb-group.com, http://www.dgb-group.com
-- Tel: +31 53 4315155 , Fax: +31 53 4315104