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

The picoQuery via DID seems to check for provides instead of shares #647

Open
b1conrad opened this issue Sep 9, 2023 · 0 comments
Open
Assignees

Comments

@b1conrad
Copy link
Member

b1conrad commented Sep 9, 2023

The provides directive identifies functions in a ruleset that can be used by other rulesets using this one as a module.

The shares directive identifies functions that can be invoked from the world outside the pico, through any of these ways:

  • through HTTP using a /sky/cloud URL, for example http://DOMAIN/sky/cloud/ECI/RID/FUNCTION
  • through the Testing tab
  • through the wrangler:picoQuery function using ctx:query for another pico hosted by the same pico engine
  • through the wrangler:picoQuery function using either an ECI or a DID

The latter, in the case of a DID passed in in lieu of an ECI ultimately uses an ECI from the DIDDoc service endpoints which include the ECI which is actually used to invoke the function. In all cases, the ECI must have a query policy that allows the function to be invoked for the ruleset that defines it.

As written, the dido library allows for a provided function to be invoked, but not a shared one. This seems wrong to me.

For example, in this commit the wrangler:picoQuery function fails with a "null is not a function" error message, when the ruleset shares the function.

OTOH, in this commit, it succeeds, when the ruleset provides the function.

Tagged as a question to get opinions from @windley and @joshmann35 .

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

No branches or pull requests

3 participants