You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As alluded to in #262 we'd like to describe our services using IPLD schemas. We are however unable to fully describe protocol because there is no notion of function so it is impossible to describe a thing that given some input type I will produce some output of type O.
Put it differently we need something along the lines of GraphQL Query and Mutations to describe the service and that is also where generics #248 become relevant as often there is correlation between input and outputs.
Our current work around is to define them as structs with a in and out fields, although it does seem like a poor mans solution forcing us to consider alternatives.
I do not have concrete proposal here, adding actual functions is probably no go. Perhaps some extensibility of the schema could be introduced however ? E.g. GraphQL has notion of directives which are often runtime specific things similarly EDN has tagged literals which also provides extensibility, maybe something along those lines could be added to IPLD schema so things like these could be developed in user space.
The text was updated successfully, but these errors were encountered:
As a side note I have also considered representing a service in terms of graph that you can patch via input and then read out state from corresponding part of the graph. However it does seem to introduce a lot of incidental complexity:
You can only patch (writable) part of the graph and need to observe results on (readable) part.
Almost all the operations need to do both
Correlation between input and output are hard to capture.
Ephemeral computation becomes impossible you always have to know retain things forewer
FVM wants(wanted?) to do a similar thing iirc. They were looking at https://github.com/ipld/edelweiss as an alternative in order to achieve this. My thoughts are that this seems like a useful area, particularly in terms of a documentation tool, and that maybe we should consider extensions to support this, maybe edelweiss has some extensions to offer. I haven't looked too much into it myself but would be interested to see proposals.
As alluded to in #262 we'd like to describe our services using IPLD schemas. We are however unable to fully describe protocol because there is no notion of function so it is impossible to describe a thing that given some input type
I
will produce some output of typeO
.Put it differently we need something along the lines of GraphQL Query and Mutations to describe the service and that is also where generics #248 become relevant as often there is correlation between input and outputs.
Our current work around is to define them as structs with a
in
andout
fields, although it does seem like a poor mans solution forcing us to consider alternatives.I do not have concrete proposal here, adding actual functions is probably no go. Perhaps some extensibility of the schema could be introduced however ? E.g. GraphQL has notion of directives which are often runtime specific things similarly EDN has tagged literals which also provides extensibility, maybe something along those lines could be added to IPLD schema so things like these could be developed in user space.
The text was updated successfully, but these errors were encountered: