New bug: Unab=
le to locate Jira server for this macro. It may be due to Application Link =
configuration.
Work on Unable to =
locate Jira server for this macro. It may be due to Application Link config=
uration.
...
Status of "in-flight" tickets
type
key
summary
assignee
reporter
priority
status
resolution
created
updated
due
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Ticket Summaries
Please squash a bug!
type
key
summary
assignee
reporter
priority
status
resolution
created
updated
due
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Tickets resolved this week:
type
key
summary
assignee
reporter
priority
status
resolution
created
updated
due
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Tickets created this week:
type
key
summary
assignee
reporter
priority
status
resolution
created
updated
due
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Minutes
Congratulations and welcome to New Fedora committer Aaron Birkland.
Fedora 4.6.0 (=
Last ModeShape4) - release testing status=20
Testing is ongoing for Fedora 4.6.0 (last Modeshape 4 release). A. Soroka: thanks to ev=
eryone who has been helping with testing, and thanks to those doing the ted=
ious work of manual testing in web browsers.
Weak/Strong ETags for Containers and the If-Match header
See Unable to=
locate Jira server for this macro. It may be due to Application Link confi=
guration.
The LDP spec says we should use If-Match when performing an update to m=
ake sure it does not overwrite another update. The HTTP spec currently does=
not allow weak e-tags on update. Currently, if a client uses strong e-tags=
, If-Match works. If the client uses weak e-tags, it returns =E2=80=9Ccondi=
tion unsatisfied. tamsin johnson=
commented on this issue, Fedora attempting to use strong validators: ht=
tps://github.com/fcrepo4/fcrepo4/pull/1089#issuecomment-23918773.  =
;There is a stringent list of requirements for strong e-tags. Not sure if t=
here is a way to meet them for RDF unless you implement some method of inte=
rnal version control.
Proposed solution: use the timestamp to indicate updates in a method si=
milar to e-tags functionality. This provides a workable alternative to the =
e-tags If-Match method of avoiding conflicts. This recommendation could go =
to the LDP community and be offered for consideration as a proof-of-concept=
workflow for RDF resources to protect edits.
Any LDP clients that are using the recommendation and are written to sp=
ec, when updating resources via PUTS, would be incompatible with Fedora in =
this implementation. However, Fedora is already incompatible. Any LDP clien=
t that is trying to faithfully follow the spec won=E2=80=99t be able to mak=
e updates unless they attempt If-Match, recognize the failure, and try anot=
her method, i.e. the header method. If a to-spec LDP client gets a weak e-t=
ag in the response, it shouldn=E2=80=99t accept it for validation. There is=
not currently a way for things to Just Work as they exist.
The software in its current state allows you to accept a weak e-tag and=
scrub the W/ to pass it along as a strong e-tag. This is a loophole that s=
hould be closed, but there is a concern about blocking off functionality to=
do so. Correcting client behavior on the server side should be a policy-dr=
iven decision, not a software-driven one. The PR's purpose is primarily to =
make this more explicit with a more useful error message, and close a looph=
ole.
Additionally, the way e-tags are used is not a back-and-forth, but two =
stateless requests that take place at two separate times. Scrubbing the W/ =
from the weak e-tag doesn=E2=80=99t make it match the spec.
In sacrificing this, we sacrifice caching and weak concurrency. If we n=
o longer accept weak e-tags (do we? have we ever?), the weak concurrency is=
taken up by the If-Not-Modified header, which is practical. Caching is all=
right as well because the tags are still out there for utilization.
The LDP community discussed in the RFC-7232 process that weak e-tags sh=
ould be allowed. The spec processes for these two things overlapped in a wa=
y that caused LDP to make an impracticable recommendation that is under rev=
iew. LDP says server should require If-Match, but if they=E2=80=99re not se=
nding strong e-tags (which no one has figured out how to do), it makes it i=
mpossible to require If-Match. This may hopefully be resolved in discussion=
s in the LDP group.
Immediate-term resolution: do nothing. Raise this with the LDP group an=
d see if we can come up with a better solution in the next few weeks. We ma=
y be overlooking a nasty edge case by leaving this in for now, but let=E2=
=80=99s try to come up with a bigger solution that=E2=80=99s generally acce=
pted, and implement that in the near term.
Recent versioning issues: =20
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Unable to locate J=
ira server for this macro. It may be due to Application Link configuration.=
Not a blocker for 4.6.0 release. Versioning works, improvement is neede=
d but not pressing.
Nick Ruest has been been spearheadin=
g. Looking for consensus on proposed priorities. If you have no=
t yet done so, please review the design priorities.
No pushback from those who responded, just consensus so far. Sche=
duling the sprint for Phase 1 priorities soon.
David Wilcox has put together a voting =
system with a variety of phrases that describe what Fedora is/does. =
li>
People are encouraged to vote on the ones that resonate with them, add =
comments if any.
Timeframe for voting and submissions: within the next week or so. Folks=
on a Steering Group call on Tuesday will be going through the data that's =
there.
The goal of this is to figure out which phrases Fedora stakeholders fin=
d the most important. Statements are about "what is Fedora?" and not =
"what could Fedora be?"
New bug: Unab=
le to locate Jira server for this macro. It may be due to Application Link =
configuration.
This bug is at the Modeshape level, an exception causes a thread to die=
, and it has not yet been determined if this can be caught at the Fedora le=
vel.
Work on Unabl=
e to locate Jira server for this macro. It may be due to Application Link c=
onfiguration.
First subticket: Process of resolving reference properties into URIs is=
very expensive in Modeshape, iterates through most of the nodes to return =
the ones needed. To address the issue, Modeshape queries need to be o=
ptimized to not do this, targeting the actual resolution to use query resol=
ution facility where possible, to cut down on node iteration. Ben has done some work around this and had som=
e positive performance findings. Esm=C3=A9 tr=
ying to replicate Ben's performanc=
e findings without success. This could mean the performance is impacted by =
something deeper in the stack.
Second subticket: preventing additional jcr:node lookups with data we a=
lready have (was this correct?)=20
Esm=C3=A9 & Aaron working on this. Looking for volunteers to help with=
this work on in its current state.
Two complexities: 1) the path and URI are not a perfect match, 2) the n=
ode lookup for the subject is not at issue, the lookups of N child nodes ar=
e. In order to put an identifier in the triple, you have to get the node to=
get that identifier. This work aims to make it so that the application doe=
s not need to get the node to get the identifier for child node references.=