#Something I don t understand in the

1 messages · Page 1 of 1 (latest)

stray jewel
#

Right now we don't have any recursive loading of cloak.yaml (since we have been figuring it is all going to be updated/refactored soon anyways). So yeah at this exact moment you have to actually declare all your transitive dependencies in cloak.yaml too, which is obviously silly.

I've been thinking about how we want to approach this when we improve it. One possibility is to update the core api to be like:

loadExtension(schema String!, resolvers Filesystem!, deps [Extension!]) Extension!

Which basically would make it up to the client loading the extension to provide the dependencies of the extension. The dependencies could be loaded by use the core filesystem api to read cloak.yaml (or its equivalent replacement) and then also recurse to each dep and call loadExtension on them.

Pros are that it's more flexible and that it gives a very obvious answer to the question of how we could enable overrides of dependencies.

Cons are that it pushes complication to the client.

Alternative would be to do the same basic idea except have it be in the cloak server itself. Basically the same tradeoff we were discussing in github discussions about what to hardcode in cloak and what to push to clients and/or extensions.

#

I'm currently leaning towards the latter (put this dependency loading logic in cloak) to start just because it's easier to understand and is fundamentally important enough that not hardcoding in cloak could lead to too much fragmentation (similar to the same question about the runtime protocol)

gaunt yew
#

Yeah I think I agree, cloak needs a built-in extension builder

#

So I think we can simply talk about what needs to be changed in cloak.yaml , if anything

#

And that’s really an architecture and terminology discussion .

#

Starting with: what is the exact relationship between a project and an extension?