Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPLD schema for function #263

Open
Gozala opened this issue Jan 5, 2023 · 2 comments
Open

IPLD schema for function #263

Gozala opened this issue Jan 5, 2023 · 2 comments

Comments

@Gozala
Copy link

Gozala commented Jan 5, 2023

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.

@Gozala
Copy link
Author

Gozala commented Jan 5, 2023

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:

  1. 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
  2. Correlation between input and output are hard to capture.
  3. Ephemeral computation becomes impossible you always have to know retain things forewer

@rvagg
Copy link
Member

rvagg commented Jan 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants