project-m36
project-m36 copied to clipboard
agentm
Could client APIs take session ID only?
The fact that client APIs take both connection and session ID implies that it's possible to have the same session ID across connections. Correct me if I'm wrong but I don't think that's true. In that case, it'd probably be better to create a session ID from a connection and have the APIs decide which connection to use behind the scenes. This would make it harder to use them incorrectly.
Could you provide more detail on what circumstance led to using them incorrectly?
It might be handy to have a simplified interface, but I suppose it would be a duplicate of the existing interface.
Perhaps a (SessionId, Connection) type alias called SessionConnection (or a better name) could be used as the first argument to the client functions instead. Would that be a acceptable compromise?
I haven't actually used them incorrectly myself, but I the fact that all the APIs ask for both seems to suggest it's ok to mix them up. If that's not the case, why not just encode that directly in the API? On the client side you could have an opaque type that is data Session = Session Connection SessionId. The downside, I suppose, is that you now have a hierarchical resource dependency instead of a flat one (i.e. now your APIs need an active Session and Session needs an active Connection).
Using a type alias could work ok. Allowing the end user to construct one manually leaves the possibility for users to mix them up still, but it does suggest the right thing.
After discussion with @3noch, I realized that it's not possible to do anything interesting with the database now without first creating a session. This is problematic, because the client may not know which head names are available. It should be possible to execute read-only transaction graph queries without a session.
To summarize, @3noch suggests hiding the session and connection objects behind an opaque type. He suggested that the current API could be wrapped, but I don't want to wrap an API that is potentially confusing.