info in kvp_frames and scheduled transactions

[Dave Peticolas]

--=-e2j6jXTYbMuz0Xf3zNZX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2001-08-22 at 21:23, Robert Graham Merkel wrote:
> While for now I'll just do the safe thing and simply ignore kvp_frames,
> what happens when=20
> we start using the kvp_frame info more heavily?  Is it going to be safe t=
o
> duplicate kvp_frame
> info as a block to insert into instantiated transactions?  Are we going t=
o
> need hooks for
> scheduled transactions to know how to deal with each key in a kvp_frame
> when instantiating?
>=20
> Is this as ugly as I think it is?

I don't think it is that ugly, as long as we are careful in what we do.

This is less a problem with scheduled transactions than it is with, say,
auto-completion. When you are auto-completing, you need to copy some=20
things, but not others (i.e., reconciled status should not be copied).
Right now, auto-completion 'ignores' kvp-frames in the sense that it
does not copy them wholesale. Of course, since some of the data elements
that are copied are stored in kvp data, some kvp data is copied.

This is one of the reasons why I maintain that we should treat kvp data
as a convenient storage implementation and define API's for accessing
all elements in engine structures. Nothing outside of the engine should
access kvp frames directly.

Then, when it comes time to copy something, you have a definite set of
API calls defining the data and you can decide on a case-by-case basis
what to do with them.

dave


--=-e2j6jXTYbMuz0Xf3zNZX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA7hJ0O5effKKCmfpIRAnHnAJ46L/v+ZUNkiTwz96gSLYVyLxCJ4wCffpTf
62inZ0o1O+zP8xAjJBPATvI=
=mSGD
-----END PGP SIGNATURE-----

--=-e2j6jXTYbMuz0Xf3zNZX--