Unsure why copying a static view is necessary about arcs HOT 7 CLOSED

If the view is only used as "in" connection, there is no need to copy (sorry, that was my bad in the recipe we discussed earlier today), you can just map, as in:
recipe
map as view0
map as view1
Greet
greeting <- view1
PersonalGreet
person <- view0

https://glitch.com/edit/#!/mmandlis-arcs-hello-world?path=arc.manifest:24:0

Can you try, if "map" works in this example too?

from arcs.

We have this requirement for low-level resolution that the resolver can't make decisions. When you've got a view reference there are 4 things you can do to it:
(1) create a new view in the arc
(2) use an existing view that's already in the arc
(3) map (readonly) to an existing view that's in a different arc
(4) copy a view from a different arc into the current arc

If you specify a constraint (HelloWorld.hello -> Greet.greeting) then there's a clear signal that you explicitly want a newly created view coordinating communications between the two particles.

Otherwise, if you have a view that isn't specified in a constraint then we default to 'use', because generally you want to "graft" a recipe onto what's already in the arc.

This leaves 'map' and 'copy' as exceptional things that you explicitly need to call out in a recipe. This is the trade-off we had to make to reduce the resolved recipe count down to something reasonable. Note that this only applies to resolution - in the future we'll hopefully be able to add some magic that can make these kinds of decision at a higher level, we just don't know how to do that yet.

Does this help?

from arcs.

Not sure it makes sense in the manifest documentation, probably a new .md specifically around how recipes are resolved.

from arcs.

That's super helpful. Thanks for the background!

Just double-checking I'm getting this right: so "use" doesn't work here because it assumes the view in the Arc to be writable which it isn't because in this case we're talking about a static view specified in the manifest?

Suggestion: could we default (or fallback) to "map" instead of "use" when views are only used as inputs in particles? That might be useful specially if "use" fails because it's a ro view.

from arcs.

No, "use" means the view is already mapped into the arc that you're applying the recipe to. "use" view references will have the same access rights as the view being referenced.

I don't think it makes sense to default to map for input-only particles because that would stop a lot of the demo from working (e.g. applying the Arrivinator wants to "use" a view inside the arc rather than "map" a new view in. Also, wouldn't ro views be fine for input-only particles? I think I must be missing something.

from arcs.

For the Arrivinator example 'use' makes sense, but I could imagine in other cases the recipe just implies "data comes from the outside" and probably wouldn't care much. E.g. the wishlist doesn't have to be 'map'ped, it could also be generated by some other particle and then 'use'd.

I.e. isn't 'use' and 'map' the same (put data in the arc before applying this recipe)? Except of course a map that also comes with a specific source to be mapped in.

from arcs.

I think this issue is obsolete.

from arcs.