Hi,
As I'll be working on the source cache I've commented on some points related to that.
[snip]
* Specific example: Server needs to be extended/updated when
introducing the SourceCache feature
I see no issue here because I don't think the SourceCache should use the same
ref service anyway.
This may be a naive opinion but I don't see why it shouldn't, they're both doing
CAS backed caching so why not use the same service, especially if the plan is to use
more scalable storage back ends anyway.
[snip]
In general I prefer the generic service as this makes it easier to
extend the client or support other clients with slightly different
feature sets. However, if there is a need for Artifact-specific logic
on the server side, it probably makes sense to have an Artifact service
instead of the generic ReferenceStorage service. However, we should
have a clear motivation for this. What do you see as main reason for
this change?
My concern with the generic service is that the semantics of the components
of an artifact, their presence or absence, under various conditions, etc, are
*implicit* in the generic structure rather than being *explicit* under a well
defined proto whose documentation makes it very clear what it means if the
buildtree value is set or unset for example.
As the ref just points to a digest, could it make sense to have it be a digest
of either an artifact proto or a directory proto? This would keep the reference
service generic (and require no changes), and allow use of the new artifact proto.
This means you would get an error if you used the wrong ref that was pointing to
the other type, but you'd want an error to be raised if this happens anyway.
There could be some issue with this I haven't thought of however.
Cheers,
Raoul
