Also, have it pass-through the raw vocab types directly to callbackers.
This will be an API breaking change for pub.Callbacker and streams.Resolver callbacks
Old code:
var r = &streams.Resolver{
CreateCallback: myFuncUsingStreams, // or myFuncUsingRaw
}
func myFuncUsingStreams(s streams.Create) {
resolution, iri := s.GetActor(0)
}
func myFuncUsingRaw(s streams.Create) {
raw := s.Raw()
iri := raw.GetActorIRI(0)
}
New code:
var r = &vocab.Resolver{
CreateCallback: myFuncUsingStreams, // or myFuncUsingRaw
}
func myFuncUsingStreams(v vocab.Create) {
s := streams.Create{Raw: v}
resolution, iri := s.GetActor(0)
}
func myFuncUsingRaw(v vocab.Create) {
iri := v.GetActorIRI(0)
}
I hope this is not a painful transition. It unblocks several other design and feature issues:
66 - Moving the resolver and sticking to the raw vocab type helps normalize the different vocabularies and extensions.
50 - This allows pub to rely only on streams, which cuts down on the complexity of someone else plugging in their own serialization/deserialization scheme with the pub library.
It ensures that the convenience library of streams is opt-in and not forced upon power users
Also, have it pass-through the raw vocab types directly to callbackers.
This will be an API breaking change for
pub.Callbacker
andstreams.Resolver
callbacksOld code:
New code:
I hope this is not a painful transition. It unblocks several other design and feature issues:
66 - Moving the resolver and sticking to the raw
vocab
type helps normalize the different vocabularies and extensions.50 - This allows
pub
to rely only onstreams
, which cuts down on the complexity of someone else plugging in their own serialization/deserialization scheme with thepub
library.streams
is opt-in and not forced upon power users