Mailing List Archive

> Most of the time, such callbacks are not necessary and everything in the
> object/structure may be saved to disk and is meaningful at restore time.

well... I wouldn't agree with that. I'd say I've found that more often
than not an object has to realize it has awakened (possibly in a new
environment) and reconnect itself to the existing delegate objects, etc.

In my particular case, there is system data that may have changed
while the object slept - it has to *know* that it must go and
update portions of itself. Also, there are some other objects whose
contains derived information and support objects which don't need
to be archived at all - they are just as easily recreated at reloadtime.

There are also cases where object version has changed - what often
happens is that the unarchived object is messaged and it then
creates and substitutes a "new" object for the one that was
unarchived. This is also very often the time when the reconnection
to local delegates occurs.

And there is much, much, more - but no need to write an OO runtime
tutorial here! :-)

Dale Amon writes:
>
> > Most of the time, such callbacks are not necessary and everything in the
> > object/structure may be saved to disk and is meaningful at restore time.
>
> well... I wouldn't agree with that. I'd say I've found that more often
> than not an object has to realize it has awakened (possibly in a new
> environment) and reconnect itself to the existing delegate objects, etc.
>
> In my particular case, there is system data that may have changed
> while the object slept - it has to *know* that it must go and
> update portions of itself. Also, there are some other objects whose
> contains derived information and support objects which don't need
> to be archived at all - they are just as easily recreated at reloadtime.
>
> There are also cases where object version has changed - what often
> happens is that the unarchived object is messaged and it then
> creates and substitutes a "new" object for the one that was
> unarchived. This is also very often the time when the reconnection
> to local delegates occurs.
>
> And there is much, much, more - but no need to write an OO runtime
> tutorial here! :-)
>
>
>

What you are discussing here is the _interface_. There _is_ such a
thing written. I'm pretty sure that while I spend a lot of time to
make it working, I missed some opportunities available to a C
implementation. Thus this interface _may_ be refined, but someone with
a working C implementation should look into it.

Unfortunately, now it looks that Raphael Manfredi's implementation is
*not* working, if I understood what he wrote correct. In particular,
if a package uses sv_setref_pv, the C pointer saved in IV will be
saved/restored as an integer, even if the package is ready to
cooperate, right?

Sorry for shouting, it is just a pain to repeat all this for upteenth
time.

Ilya

Quoting Dale Amon:
:I'll have to take a look at your package. Does it message the
:objects at the appropriate times during the unarchive and does
:it allow them to select which data they wish to put out during the
:archive process?

No, it does not. It saves everything in the object, and restores it
as-is. That's more a chekpoint/restart.

:You have to have a root Object Class to do it "right" in the OO purist
:sense so that all objects inheirt the basic methods for replying to
:the archive and unarchive process.

This is not the minimal support layer needed for stock perl5. I wanted
to provide basic services using C as the implementation, and rely on
callbacks to do selective work. That callback support is not implemented
yet, though.

Most of the time, such callbacks are not necessary and everything in the
object/structure may be saved to disk and is meaningful at restore time.

Raphael

> From: Raphael Manfredi <ram@hptnos02.grenoble.hp.com>
> [...]
>
> Have you looked at my Storable-0.1 extension, on CPAN? If not, please
> do. It looks like you're re-inventing the wheel again.
>
> How many distinct persistant object packages do we want?
>
> Raphael
>
> P.S.: BTW, Gurusamy, I'm still waiting for your code to integrate it into
> Storable-0.1...
>
> P.P.S: We should really agree on a set of minimal features required for
> persistency and stick with it. Then make the Storable extension (or
> whatever it gets named) part of standard Perl. Based on the amount of
> people getting the same thing done again and again, there is surely
> a need that need to get filled up, quickly.

Raphael, I'd love to see a discussion on the features and the interface
for this functionality.

I'd especially like to see a summary of your current and future
interface plans in relation to the interface developed by Ilya
and embodied in the FreezeThaw module.

Tim.

p.s. This probably belongs in a comp.lang.perl.modules newsgroup
(but that's another story)