search

fcrepo4-labs / derby

A pure Ruby Fedora Commons implementation.
Apache License 2.0
5 stars 4 forks source link

FCR API must define PUT-to-create-objects #11

Open cbeer opened 8 years ago

cbeer commented 8 years ago

4.2.4.6 LDP servers may choose to allow the creation of new resources using HTTP PUT.

Obviously, FCR API needs a stronger requirement.

ajs6f commented 8 years ago

@cbeer Can you say a little more about this?

cbeer commented 8 years ago

LDP says:

Per [RFC7231], this HTTP method is optional and this specification does not require LDP servers to support it.

I think our API ought to require support for PUT.

no-reply commented 8 years ago

I think our API ought to require support for PUT.

I think I caught @barmintor advocating remaining silent, last week.

My feeling is if Fedora requires PUT creation, it should specify clear behavior for handling containments for resources created in this way. But I think I'm fine with remaining silent, too.

The current draft says: "LDP-RS SHOULD support PUT to update user data". So at this stage, we aren't even floating requiring PUT at all.

ajs6f commented 8 years ago
  1. I agree with @no-reply that if we require it, we are obliged to specify it fully.
  2. @cbeer, thanks, but that doesn't really clarify much for me at all. Can you explain why you think the API should require support for PUT?
cbeer commented 8 years ago

@ajs6f Well, for one, how else are we going to create containers in the first place? Or, do we require the root of the repository is itself a container?

ajs6f commented 8 years ago

@cbeer Currently we do make that happen in the ref impl, and I have no problem with writing that into the spec. On the other hand, one of the issues that @no-reply and I and others discussed around this was in what way the repository does and does not have to be connected via LDP containment. We came to the rough conclusion in an IRC chat that the multitenancy use case suggests that the repository does not have to be entirely connected, which would suggest that PUT be available in order to create new roots/tenants. But that discussion didn't include you, so I want to understand your thinking on this.

no-reply commented 8 years ago

Discussion at LDCX was generally against PUT for create, and against repositories without contiguous containment. The main reason given for this was that node discovery is basically impossible in this case.

For my part, this seems like an orthogonal issue. REST generally doesn't define discovery, and I'm not sure an LDP server in general, or Fedora in particular, needs to either.

ajs6f commented 8 years ago

Not totally clear what the phrase "node discovery" means in this context-- are we talking about how to find out where a repository exists?

no-reply commented 8 years ago

@ajs6f "node" here meaning "LDP Resource". Sorry for lack of clarity.

Given a Fedora instance, resources connected to the repository base will be navigable via containment. Any free floating resources would not.

ajs6f commented 8 years ago

In that case I agree with you, @no-reply. This reminds me of my (weak cheese) "Google crawler" use case. IIRC, in that conversation you and I came to the conclusion that an instance of Fedora may usefully include several "regions"/tenants/workspaces/staging areas/whatever-you-want-to-call-them, each one being a containment-connected subgraph, without the full repository being containment-connected. I still think that's true. I'd like to hear more about the use cases for node discovery. Are we still talking about crawlers?

ajs6f commented 7 years ago

As we bring the initial phase of spec writing to a close, it would be helpful if y'all (especially @cbeer and @no-reply) could opine at the current place for discussion. I myself am very inclined to the idea of create-on-PUT, but it's not clear to me that we must require it in the spec. Maybe you can help?

barmintor commented 7 years ago

I think if we require it than we must also specify the containment and intervening node issues. My 10-seconds-of-thought in this direction ends up so fiddly that I suspect it's a bad idea.

On Thu, Nov 3, 2016 at 10:35 AM, A. Soroka notifications@github.com wrote:

As we bring the initial phase of spec writing to a close, it would be helpful if y'all (especially @cbeer https://github.com/cbeer and @no-reply https://github.com/no-reply) could opine at the current place for discussion https://docs.google.com/document/d/1ad3MhTQWGof0IJ03yY5jVofCK8uO9yPKMVXVYq7a44o. I myself am very inclined to the idea of create-on-PUT, but it's not clear to me that we must require it in the spec. Maybe you can help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fcrepo4-labs/derby/issues/11#issuecomment-258159839, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHUNGJ9AjWtNzbtI408F2qYiwjvDW8bks5q6fE3gaJpZM4HX5Q7 .

ajs6f commented 7 years ago

My sense of those issues is straightforward-- no containment required (meaning an impl MUST NOT do auto-containment, and multiple, uncontainment-connected regions within a server are fine) and no intervening node-creation required (impls MAY produce intervening nodes). Is that problematic?