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

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

Open
cbeer opened this issue Feb 11, 2016 · 13 comments
Open

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

cbeer opened this issue Feb 11, 2016 · 13 comments
Labels

Comments

@cbeer
Copy link
Collaborator

cbeer commented Feb 11, 2016

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.

@cbeer cbeer added the fcr api label Feb 11, 2016
@ajs6f
Copy link

ajs6f commented Feb 23, 2016

@cbeer Can you say a little more about this?

@cbeer
Copy link
Collaborator Author

cbeer commented Feb 23, 2016

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
Copy link
Member

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
Copy link

ajs6f commented Feb 24, 2016

  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
Copy link
Collaborator Author

cbeer commented Feb 24, 2016

@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
Copy link

ajs6f commented Feb 24, 2016

@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
Copy link
Member

no-reply commented Apr 1, 2016

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
Copy link

ajs6f commented Apr 1, 2016

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
Copy link
Member

no-reply commented Apr 1, 2016

@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
Copy link

ajs6f commented Apr 1, 2016

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
Copy link

ajs6f commented Nov 3, 2016

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
Copy link

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 [email protected] 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
#11 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHUNGJ9AjWtNzbtI408F2qYiwjvDW8bks5q6fE3gaJpZM4HX5Q7
.

@ajs6f
Copy link

ajs6f commented Nov 3, 2016

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?

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

No branches or pull requests

4 participants