To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Fedora Tech" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedora-tech/kMVBaX5kViU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedora-tech+unsubscribe@googlegroups.com.
Peter Eichman
Senior Software Developer
University of Maryland Libraries
--
You received this message because you are subscribed to a topic in the Google Groups "Fedora Tech" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedora-tech/kMVBaX5kViU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
Hi all,
A little worried that too much information is being encoded in the external body mime type, it gives the impression of hack-upon-hack-upon-hack. For me, things started to get a little uncomfortable with using the ‘expires’ header to mean “the server MUST copy this”; now the concern is encoding mime types in mime types. It can be done if the spec is explicit and clear about it, but it makes me want to think if a different approach might be more straightforward.
I wonder it’s possible to make things a bit more manageable (and explicit) by defining a number of _Prefer_ headers to specify a client’s intent (which the server may or may not obey, but has the Preference-Applied mechanism by which to communicate what it ended up doing). I think such an approach might be a more flexible going forward for implementations that would _like_ to approach external content via redirects where it makes sense, or for implementations that only do proxying, etc.
Imagine if a request could use one of these Prefer headers (or something like them):
Prefer: external-content; method=”copy”
Prefer: external-content; method=”proxy”
Prefer: external-content; method=”redirect”
.. then used the Content-Location header to provide the external content location, and Content-Type to specify *its* content type.
So the meaning of the prefer header is something like “Please handle this as external content using the requested mechanism”.
So something like:
POST /path/to/container
Content-Type: video/mpeg
Prefer: external-content; method=”proxy”
Content-Location: file:/path/to/file
Then the response:
HTTP/1.1 201 Created
Preference-Applied: external-content; method=”proxy”
Content-Type: video/mpeg
Content-Location: file:/path/to/file
Location: http://my.server.example.org/path/to/container/abc123
.. or let’s say we wanted to ingest-by-reference
POST /path/to/container
Content-Type: video/mpeg
Prefer: external-content; method=”copy”
Content-Location: http://example.org/videos/funny_cat_video.mpg
The server could suitably respond
HTTP/1.1 202 Accepted
Preference-Applied: external-content; method=”copy”
Location: http://my.server.example.org/path/to/container/abc123
(meaning “yes, you asked me to copy. I’m attempting it, but have no idea if it’ll be successful or how long it’ll take. Check the messaging bus for indication of success”)
I don’t think the “access-type” part of the external body spec brings much to the table; the server would use the URI scheme of the provided Content-Location to know how to dereference it.
Would exploring this sort of approach further be helpful?
-Aaron
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
1. The expires parameter is ambiguous on mutating requests, so we stopped referring to/relying on it.
2. No matter how much we wanted it to, Content-Location seemed specifically defined not to act as a pointer in lieu of the entity (whereas message/external-body specifically is); we also discussed using a Location header on PUT/POST but if I remember correctly rejected as being an undefined use of a specified header.
3. Content-Location on PUT/POST is also undefined, and we tried to minimize unspecified behaviors in the spec
4. see also the Prefer headers
I think for my part not specifying whether the content is available as redirect or proxy in the spec is probably a good idea,
Hi all,
In general, I’m a fan of placing specialized, controversial, or new/untested aspects of the spec into ‘sidecar’ specs (like transactions, external content) and see where things land. At the very least, this means that behaviour is written down in a public place for reference, comment, and evolution. Some day, it might make sense for these sidecar specs to become an essential part of Fedora; other times they may die. Done this way, there’s at least a chance that another implementation will align on the same sidecar spec (or maybe somebody writes an API-X extension to implement a sidecar spec). Maybe calling them RFCs (and numbering them) is better.
Another thing to consider is that the spec aims to be released once there are *two* implementations. For one reason or another several implementations have no specific intention of complying with the Fedora spec fully:
It would be great if these were all fedoras too; in my mind they basically are. Exploring different aspects of linked data/repository space from different angles is a good thing. Although specs are all about technicalities, it would be a shame that these aren’t fedoras *because* of a technicality. The work by the spec editors has been great, maybe shifting things around a bit and making the core a little bit leaner is all we need. A dialog between the various implementers of fedoras and the spec team (maybe just a thread on fcrepo-tech, or the spec GitHub repo, or whatever) with the goal of negotiating and landing N compliant implementations would be fruitful?
Too bad it’s so close to the OR deadline – a panel of fedora implementers (focusing on different priorities, lessons learned) would be a great proposal .
-Aaron
--
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
The compromise on which we landed is to:1. Make the feature optional.
"In the case that a Fedora server does not support external LDP-NR content, all message/external-body messages must be rejected with 415 (Unsupported Media Type)." - https://fedora.info/2017/11/27/spec/#external-content
2. Provide guidance for consistency of approach across implementations in support of the goal to minimize the need for modifications to client applications in order to work with different implementations of the Fedora API Specification.
Part of the validation process for the specification is to have multiple implementations. If we find that certain aspects of the specification are unreasonable to implement, that is good reason to revisit the appropriateness of a given requirement. In the meantime, the specification continues to be guided by the goals above.
1. Strengthening. (I.e. requiring optional features from an underlying spec)
For example, PUT and PATCH are optional features of LDP, but Fedora requires them. All of these requirements are implemented in Trellis. These requirements do eliminate the possibility of a read-only Fedora repository, but I don't see anything fundamentally wrong with these requirements. This class of requirements also builds on existing interaction patterns defined in the underlying specifications.
2. Narrowing. (I.e. requiring one particular pattern when many are possible)
One feature of these underlying specifications is that they provide flexibility for implementations while retaining a semantically consistent model for interaction. An example of this is the Memento Datetime negotiation. The Memento specification describes several semantically equivalent patterns for discovering a Memento resource from an Original Resource (section 4 -- there are eight patterns described). But Fedora requires that one particular pattern MUST be implemented. It so happens that this pattern is the same one that Trellis implements, and while one can make an argument as to why that particular pattern makes sense for a repository, it also eliminates other possibilities. In particular, imagine the case where your data outlives your software (in my experience, this is pretty common): in this case, it may make good sense to separate your version management system from the repository resources. However, that implementation pattern is simply not possible with the Fedora specification, and there is no explanation for why such a pattern is required. In my mind, this category of requirements isn't exactly problematic, but it is questionable.
3. Inventing. (I.e. creating new behaviors or semantics)
These are requirements where there is no precedent, no prior art and no clear justification. There are quite a few requirements in this category, and in writing Trellis, I ignore almost all of these. This is the category that I find explicitly problematic. Here are a few examples:
a) The definition of an interaction pattern for defining ACL locations upon resource creation via link headers. There is no released software anywhere that does this. And there are problems with this, since it allows one to completely circumvent the acl:Control mode of an ACL resource, thereby escalating a user's permission such that they can become an administrator for a segment of the repository (this is a *serious* security hole that the Fedora spec opens up).
b) The Fedora specification requires this header for TimeGate resources:
Link: <http://mementoweb.org/ns#TimeGate>; rel="type"
It is worth noting that there is already a mechanism for finding TimeGate resources by following this header on any OriginalResource:
Link: <TimeGate URL>; rel="timegate"
and then noting that the linked resource (whether it is the same as the OriginalResource or not) contains a "Vary: Accept-Datetime" header. So why is this new header a requirement? And wouldn't such a feature encourage clients to bypass the already well-defined Datetime interaction model of Memento?
I see this category as a new type of "Fedora-ism": something that will need to be written specially for Fedora clients and which will likely exist nowhere outside of the Fedora community. I wonder why these are strict requirements (MUST) and not optional features (MAY). As optional features, they can be given time to mature in production settings before they move into hard requirements of all Fedora implementations.
Given that Trellis already doesn't conform to the Fedora specification (because of the requirements that are in conflict with a distributed implementation), there is no incentive for me to implement any of the requirements in the third category above. I would note, however, that it would be fairly easy to write an API-X extension or even a JAX-RS filter that would convert a Trellis-based server into a conforming Fedora server (modulo the requirements that the repository be strongly consistent and atomic). Is there a middle ground on these features? Yes, of course, but as it is, I have not heard a clear rationale for any of these ("Inventing category") features.
Regards,
Aaron Coburn
--
You received this message because you are subscribed to a topic in the Google Groups "Fedora Tech" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedora-tech/kMVBaX5kViU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedora-tech+unsubscribe@googlegroups.com.
> To unsubscribe from this group and all its topics, send an email to fedora-tech+unsubscribe@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at https://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at https://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Fedora Tech" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedora-tech/kMVBaX5kViU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedora-tech+unsubscribe@googlegroups.com.
Hi Bens A and P,
I really like the suggestion that we ought to aspire to inclusion in the IANA list of preferences. What we’re doing with external content is quite different from anything on the IANA list at present, so I think that taking a rigorous approach to defining a new preference is the right way to proceed. It would be ideal if we actually submitted a proposal for inclusion on that list, even if it isn’t taken up due to the specialized nature of external content (but If it *is*, that would be fantastic. It would really broaden the communities that are interested in these sort of concepts).
I also think we ought to get feedback from some of the members of the broader IETF community. I don’t think there is broad agreement with our *own* community that external content has fully landed in a manner that meets our various disparate needs, but I think this conversation gets us closer. Some “disinterested” external input might be helpful. I’d love, for example, to float some of the ideas related to external content by the IETF HTTP working group. That could help answer the Content-Location vs message/external-body questions, as well as get feedback on the proposed Prefer headers.
Anyway I like where this is going. I also like the name “content-resolution” for naming the proposed preference. I haven’t had time to fully review and think about the entirety proposal in the gist, but plan to have more feedback
-Aaron
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.