EEI: Account handle about design

[lrettig]

split the account loading from the accessing account metadata

Makes sense to me, and seems to better reflect the actual I/O cost of the operation.

[pepyakin]

This is simpler, but might waste some memory when contract is not interested in all data

is this really an issue? memory size is neglegible and the copy cost is dwarfed by the IO

Is is also not extensible, i.e. we cannot change the account representation in the future.

It can be mitigated easily though, by adding bitflags, integer or another versioning mechanism

[chfast]

Is is also not extensible, i.e. we cannot change the account representation in the future.

It can be mitigated easily though, by adding bitflags, integer or another versioning mechanism

I believe that's not enough. If you deploy a contract that supports the current version 1 there is no way to support future version 2. Maybe the contract should specify what account fields it is interested in. I added this idea as the alternative #2.

[pepyakin]

I believe that's not enough. If you deploy a contract that supports the current version 1 there is no way to support future version 2.

Could you explain me why that matters? A contract is written against version 1 and explicitly requests v.1 and gets the result in v.1, that sounds good to me and I can't see a reason why it should care about v.2 or something (unless you want to do something like a dynamic proxy that requests and forwards some account data and while it should be forward-compatible).

Maybe the contract should specify what account fields it is interested in.

Yeah, that's what i meant by bitflags : )

[chfast]

Could you explain me why that matters? A contract is written against version 1 and explicitly requests v.1 and gets the result in v.1, that sounds good to me and I can't see a reason why it should care about v.2 or something (unless you want to do something like a dynamic proxy that requests and forwards some account data and while it should be forward-compatible).

Yes, that will work. For that I'd rather suggest using different function names for new versions. E.g. loadAccountV2().

Previously, I though you meant to return the format version number as a part of the account structure.

[pepyakin]

Previously, I though you meant to return the format version number as a part of the account structure.

Ah sorry for that, I was writting on the go back then. Should have make this more clear

[chfast]

@pepyakin do you have anything similar in pwasm?

[pepyakin]

Nope, we don't!