Write impl/prod directly in terms of the protobufs?

[riannucci]

Not sure how hard this would be, but it might be easier than it seems. This would allow the removal of all of the reflection code in the 'Raw' paths for impl/prod (because currently the SDK does some reflection, but we try to bypass/shortcut it).

This might be a long-term maintenance issue, however, if the protos change frequently/semi-frequently.

[riannucci]

Not only would this allow removal of the extra reflection code in impl/prod, but it would enable:

• cleaner transaction semantics (e.g. explicit TransactionID in context, which inspectable, closable, settable, nillable)
• cleaner namespace semantics (could actually remove a namespace, which is currently impossible with the actual SDK)
• could actually implement Make impl/memory compatible with appengine.APICallFunc hooks to allow existing codebases to use it. #37
• could potentially even turn luci/gae into the basis for a (fast) dev_appserver replacement (which would bring speedup benefits to other appengine languages). Could potentially design this one to support multiple connections with separate datastore instances, so that unittests in other languages could each operate with a clean datastore. Could potentially add RPCs to control e.g. the Testable() interface methods on a per-connection basis.

Getting really frustrated around transaction * namespace manipulation semantics.

[riannucci]

Oh, and it would also mean that some of the custom encodings could be replaced with the actual protos (e.g. Property objects could have more-native binary representations), which might further reduce the amount of code in e.g. impl/memory.

[riannucci]

If the transaction and namespace are explicit, this would also allow us to remove the filter apis in favor of simply extracting the current client, applying a filter to it, and putting the new, filtered, client back into the context, which I think @vadimsht would like (really: everyone would like that, but I know vadim's been bugged by the filter API in the past, and I'm personally not a huge fan of it either) 😄

[riannucci]

Ran into the transaction crap again when implementing DM: there's no way in a tumble mutation to ditch the current transaction when handing the context off to a distributor implementation. For now distributor implementations will have to use the GetNoTxn methods, but it would be much better if we could just do a c = gae.SetTransaction(c, nil).

[riannucci]

And GetNoTxn is still terrible: If the method which needs to ignore the transaction passes the context to some other method, that inner method also needs to be written to ignore the current transaction. Ugh.