Digging around in the codebase makes the the general idea behind AuthenticatedV and the associated bits clear. However, it's not clear how one should implement viewselector and notification handlers:
serveVessel and the various pipeline combinators bake in an assumption that clients are represented as MonoidalMap ClientKey. If the outermost vessel in an app is AuthenticatedV, then the signature of the view selector handler implemented with handleAuthenticatedQuery must how we are to implement the natural transformation AuthFooV (Compose (MonoidalMap ClientKey) (Const SelectedCount)) ~> AuthFooV Proxy necessary to use handleAuthenticatedQuery is not obvious. It seems like we shouldn't even need to deal with ClientKeys in an AuthenticatedV context because AuthenticatedV assumes the client is giving us a token that must be capable of mapping back to the client in the case where the data depend on the token (and on cases where it does not, we don't care about clients at all, we just give all of them the same information). So maybe AuthenticatedV isn't designed to be used with serveVessel and does not yet have a high-level backend combinator. (Though this is weird since there's high-level API and frontend combinators.)
If we need to implement backend combinators, it's not clear at which level they should be implemented, at least not clear enough to attempt one with reasonable assurance of a correct implementation.
What's the intended use age of AuthenticatedV apps and serveDbOverWebsockets?
Digging around in the codebase makes the the general idea behind
AuthenticatedVand the associated bits clear. However, it's not clear how one should implement viewselector and notification handlers:serveVesseland the various pipeline combinators bake in an assumption that clients are represented asMonoidalMap ClientKey. If the outermost vessel in an app isAuthenticatedV, then the signature of the view selector handler implemented withhandleAuthenticatedQuerymust how we are to implement the natural transformationAuthFooV (Compose (MonoidalMap ClientKey) (Const SelectedCount)) ~> AuthFooV Proxynecessary to usehandleAuthenticatedQueryis not obvious. It seems like we shouldn't even need to deal withClientKeys in anAuthenticatedVcontext becauseAuthenticatedVassumes the client is giving us a token that must be capable of mapping back to the client in the case where the data depend on the token (and on cases where it does not, we don't care about clients at all, we just give all of them the same information). So maybeAuthenticatedVisn't designed to be used with serveVessel and does not yet have a high-level backend combinator. (Though this is weird since there's high-level API and frontend combinators.)If we need to implement backend combinators, it's not clear at which level they should be implemented, at least not clear enough to attempt one with reasonable assurance of a correct implementation.
What's the intended use age of
AuthenticatedVapps andserveDbOverWebsockets?