Hi,
I think the discussion about the adapter pattern is orthogonal to the
binary issue. According to YAGNI we should stick with instance of checks
unless we already have a somewhat clear picture of future extensions.
Michael
On 24.08.17 07:28, Chetan Mehrotra wrote:
Based on the feedback so far below is revised proposal
1. Define a new Adaptable interface in 'org.apache.jackrabbit.oak.api'
public interface Adaptable {
/**
* Adapts the binary to another type
*
* @param <AdapterType> The generic type to which this type is adapted
* to
* @param type The Class object of the target type
* @return The adapter target or <code>null</code> if the type cannot
* adapt to the requested type
*/
<AdapterType> AdapterType adaptTo(Class<AdapterType> type);
}
2. Have the binary implementation in Oak implement Adaptable
3. Have a minimal implementation in Oak on line of Sling Adaptor support [1]
For current usecase we would provide an adaptation to SignedBinary
public interface SignedBinary {
URI getUri()
}
Chetan Mehrotra
[1]
https://github.com/apache/sling/tree/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter
On Wed, Aug 23, 2017 at 10:04 PM, Chetan Mehrotra
<[email protected]> wrote:
Hence, why not simply use binaryProp instanceof SignedBinary ?
As Julian mentioned it would make it tricky to support multiple
extensions with various permutations. Having adapter support for
simplify the implementation
No client should be issued a signed url that could be used in the distant
(relatively) future bypassing fresh ACL constraints saved to Oak.
Fair point. Then lets drop the ttl paramater
Chetan Mehrotra
