Hi oak-dev, Here is the latest on this proposed change.
- I’ve made most of the minor fixes requested in the main pull request: https://github.com/apache/jackrabbit-oak/pull/88 - Marcel has asked that I submit a separate pull request for one change in PR #88, namely to add a filter to exclude “org.apache.jackrabbit.oak.plugins.value.jcr” from BND evaluation in oak-parent/pom.xml. I’ve done this and made a new pull request: https://github.com/apache/jackrabbit-oak/pull/89 - Julian has raised a concern in PR #88 in which he expresses a desire to use the URI class instead of the URL class. While PR #88 still uses URL, I’ve made another pull request using URI instead: https://github.com/apache/jackrabbit-oak/pull/90 If you have an opinion on this matter please weigh in at OAK-7574. - Marcel has asked that API changes in PR #88 be moved out of oak-jcr and into another location. In OAK-7589 he expresses this in more detail and expressed a preference to move these API changes into jackrabbit-api. I’ve submitted a pull request to jackrabbit-api with this change: https://github.com/apache/jackrabbit/pull/59 Since this change would require modifications to my original pull request to work, I submitted another pull request to Oak which relies on the jackrabbit-api changes. This new pull request is at: https://github.com/apache/jackrabbit-oak/pull/91 Michael has also asked me to try to simplify the original pull request to make it easier to follow. I’ve intended to do so but simply have not had the time, I apologize. Can progress be made with things as they are currently? Maybe there are still some issues to be resolved, but if some of the supporting pull requests can be accepted at least that would be a good start. Thanks -MR On June 21, 2018 at 9:24:44 PM, Matt Ryan ([email protected]) wrote: On June 21, 2018 at 6:53:44 AM, Marcel Reutegger ([email protected]) wrote: Hi Matt, New files in your pull request have a different format for the Apache License header. Can you please change them to match the format of existing source files? Yes - I believe I have fixed this now, let me know if I missed any. As mentioned in an offline conversion with you already, I'm a bit concerned of the impact this optional feature has on nearly all layers of Oak. SessionImpl implements HttpBinaryProvider, MutableRoot implements HttpBlobProvider, SegmentNodeStore implements HttpBlobProvider, DocumentNodeStore implements HttpBlobProvider. E.g. the last two just pass through calls they are not concerned with. Alternatively, could you do the required plumbing on construction time? That is, if the BlobStore implements HttpBlobProvider register it with that interface as well and use it to construct the repository. Something like: BlobStore bs = ... NodeStore ns = ... Jcr jcr = new Jcr(ns) if (bs instanceof HttpBlobProvider) jcr.with((HttpBlobProvider) bs) Repository r = jcr.createRepository() By default, the Jcr factory would have a HttpBlobProvider implementation that doesn't support the feature, which also relieves the repository implementation from checking the type or for null on every call to the new feature (as is the case in SessionImpl, MutableRoot, DocumentNodeStore, SegmentNodeStore). I added OAK-7570 to discuss this. I would also prefer if the API used by the client is moved to a separate module that can be release independently. Yes, we don't do this right now in Oak, but this may be a good opportunity to try this again. Releasing the API independently with a stable version lowers the barrier for consumers to adopt it. I added OAK-7571 to discuss this. -MR
