Il giorno gio 24 ago 2017 alle ore 10:16 Michael Dürig <mdue...@apache.org>
ha scritto:
>
>
> On 24.08.17 09:27, Ian Boston wrote:
> > On 24 August 2017 at 08:18, Michael Dürig <mdue...@apache.org> wrote:
> >
> >>
> >>
> >> URI uri = ((OakValueFactory) valueFactory).getSignedURI(binProp);
> >>
> >>
> > +1
> >
> > One point
> > Users in Sling dont know abou Oak, they know about JCR.
> >
> > URI uri = ((OakValueFactory)
> > valueFactory).getSignedURI(jcrNode.getProperty("jcr:data"));
> >
> > No new APIs, let OakValueFactory work it out and return null if it cant
> do
> > it. It should also handle a null parameter.
> > (I assume OakValueFactory already exists)
>
> No, OakValueFactory does not exist as API (yet). But adding it would be
> more inline with how we approached the Oak API traditionally.
>
> I'm not against introducing the adaptable pattern but would like to
> understand whether there is concrete enough use cases beyond the current
> one to warrant it.
>
+1, currently I much prefer such a concrete approach over the adaptable;
not that it's bad per se, just I am not sure there'll be other use cases.
That said, although I understand the use cases and requirements, this still
seems to me a break into the fundamental Oak design, sorry.
It's not I'm totally against it, it's just that perhaps we should rethink
some of our design if it can't stick to our requirements, e.g. provide an
API for accessing binaries at the storage layer, which we expect to be used
by consumers having the right privileges by decorating it with something
similar to a JWT [1] token, emitted by the repo.
my 2 cents,
Tommaso
[1] : https://jwt.io/
>
> Michael
>
> >
> > If you want to make it extensible
> >
> > <T> T convertTo(Object source, Class<T> target);
> >
> > used as
> >
> > URI uri = ((OakValueFactory)
> > valueFactory). convertTo(jcrNode.getProperty("jcr:data"), URI.class);
> >
> > The user doesnt know or need to know the URI is signed, it needs a URI
> that
> > can be resolved.
> > Oak wants it to be signed.
> >
> > Best Regards
> > Ian
> >
> >
> >
> >> Michael
> >>
> >>
> >>
> >>
> >>> A rough sketch of any alternative proposal would be helpful to decide
> >>> how to move forward
> >>>
> >>> Chetan Mehrotra
> >>>
> >>>
> >
>
