No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Questions about the Serializer
From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 11 Apr 2006 11:30:09 -0600
I'm using XOTcl objects to control hardware, and I'm trying to use the Serializer to persist
hardware configurations. However, I've run into a couple of issues.
1) Not all of the object state is the consistent across serialization/deserialization. The hardware
handle, for instance, may not be the same at deserialization time as it was when serialization
occurred. What I'd like to do is remap some member variables to un-substituted variables ("-set
hwhandle $handle" instead of "-set hwhandle 0x1234"), and then I'll set the variable to the correct
value when restoring the configuration. I see a way to ignore variables and a way to remap object
names, but is there a way to remap variables? Short of a global regsub on "Serializer
deepSerialize" return result, that is?
2) The serializer bypasses initialization (-noinit), and basically just restores the internal state
of the object. But in my application, I need to bring the hardware state into sync with the xotcl
object, so just setting xotcl state variables doesn't suffice. Is there an easy way when
deserializing to have some code executed after the object's state has all been restored? Something
like a -noinit flag, but instead have a custom -init?
Maybe instead of "-noinit", objects should have a "-init method" flag that determines the
initialization mechanism? If the flag is not set, or is set to "init", the "init" method is invoked
(default behavior), if the flag is set to some arbitrary method ("-init hwsync"), that arbitrary
method gets invoked, and if the flag is set to an empty list ("-init {}"), no init method is
invoked.
Scott
Notice
The information in this message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is unauthorized. If you are not
the intended recipient, any disclosure, copying or distribution of the message, or any action
taken by you in reliance on it, is prohibited and may be unlawful. If you have received this
message in error, please delete it and contact the sender immediately. Thank you.
Date: Tue, 11 Apr 2006 11:30:09 -0600
I'm using XOTcl objects to control hardware, and I'm trying to use the Serializer to persist
hardware configurations. However, I've run into a couple of issues.
1) Not all of the object state is the consistent across serialization/deserialization. The hardware
handle, for instance, may not be the same at deserialization time as it was when serialization
occurred. What I'd like to do is remap some member variables to un-substituted variables ("-set
hwhandle $handle" instead of "-set hwhandle 0x1234"), and then I'll set the variable to the correct
value when restoring the configuration. I see a way to ignore variables and a way to remap object
names, but is there a way to remap variables? Short of a global regsub on "Serializer
deepSerialize" return result, that is?
2) The serializer bypasses initialization (-noinit), and basically just restores the internal state
of the object. But in my application, I need to bring the hardware state into sync with the xotcl
object, so just setting xotcl state variables doesn't suffice. Is there an easy way when
deserializing to have some code executed after the object's state has all been restored? Something
like a -noinit flag, but instead have a custom -init?
Maybe instead of "-noinit", objects should have a "-init method" flag that determines the
initialization mechanism? If the flag is not set, or is set to "init", the "init" method is invoked
(default behavior), if the flag is set to some arbitrary method ("-init hwsync"), that arbitrary
method gets invoked, and if the flag is set to an empty list ("-init {}"), no init method is
invoked.
Scott
Notice
The information in this message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is unauthorized. If you are not
the intended recipient, any disclosure, copying or distribution of the message, or any action
taken by you in reliance on it, is prohibited and may be unlawful. If you have received this
message in error, please delete it and contact the sender immediately. Thank you.