In the javascript wallet interfaces we sometimes assume local objects, in ways that make it harder to integrate with external APIs, @sudeshrshetty you pointed this out a while back and we dropped the map / reduces query interfaces... but we still have a problem with this in the sample implementation.
There are some dangerous assumption hidden in here, like that wallet.contents might not be fresh...
This format also conflicts some with the wallet persistence mechanisms like EDVs, Transmute's current solution to this works, but its not super performant.
I'd like to explore alternatives for contents in this issue with an eye towards JSON-LD purity and async persistence.
A filter is a query, we should avoid any kind of direct array accesss
I think this is the biggest problem, once you start assuming you have an array, you stop defining the higher order interfaces you need, and then you can't get rid of the array assumption.
Wallet.contents ~== wallet.getAllContentAsync
This is a pretty unreasonable assumption to make in any environment.
get / set map to key value systems
can we expose better lower level interfaces than add / remove, that teach developers how to organize content better?
Stateful operations are really hard right now
In a lot of places in our code, we are doing things like this:
await wallet.syncWithEdv(...) // setup wallet state
await wallet.performStatefulProtocolOperation(...)
await wallet.syncWithEdv(...) // persist state from operation above
^ the worst part of this is the assumption about "setup state"... for example, what if critical objects needed by performStatefulProtocolOperation are not present? then they need to be created first... but what if they can't be created?
we are often searching in an array of objects to answer these questions... there must be a better way.
Consider get, set, and Object.values.
In the javascript wallet interfaces we sometimes assume local objects, in ways that make it harder to integrate with external APIs, @sudeshrshetty you pointed this out a while back and we dropped the map / reduces query interfaces... but we still have a problem with this in the sample implementation.
All over our code we are doing things like this:
There are some dangerous assumption hidden in here, like that wallet.contents might not be fresh...
This format also conflicts some with the wallet persistence mechanisms like EDVs, Transmute's current solution to this works, but its not super performant.
I'd like to explore alternatives for
contentsin this issue with an eye towards JSON-LD purity and async persistence.I think this is the biggest problem, once you start assuming you have an array, you stop defining the higher order interfaces you need, and then you can't get rid of the array assumption.
This is a pretty unreasonable assumption to make in any environment.
can we expose better lower level interfaces than add / remove, that teach developers how to organize content better?
In a lot of places in our code, we are doing things like this:
^ the worst part of this is the assumption about "setup state"... for example, what if critical objects needed by
performStatefulProtocolOperationare not present? then they need to be created first... but what if they can't be created? we are often searching in an array of objects to answer these questions... there must be a better way.