incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hasan Hasan <>
Subject Re: [VOTE] Accept the proposed patch of CLEREZZA-540
Date Fri, 27 May 2011 09:21:19 GMT

please see my comments inline

On Thu, May 26, 2011 at 8:31 PM, Reto Bachmann-Gmuer <> wrote:

> With CLEREZZA-540 I suggest a GraphNodeProvider-Service that returns a
> GraphNode given a named resource. Mainly this code that used to be in
> DiscoBitsTypeHandler which has been generalized.

I support generalization of functionality to allow flexible reuses.

> The issue is described as:
> "Implement a platform service that returns GraphNodes for URIs. The
> GraphNode is the resource identified by that uri with as BaseGraph sources
> considered authoritative for that resource. "
> Of course "considered authoritative" it not a very sharp description.

This is one main point of the debate between Henry and Reto as can be seen
by following their comments on jira. Since the javadoc defines what that
means I can live with that.

> The
> issue is labeled with "platform" which implies it is not a generic utility
> of clerezza.rdf but that it relies on platform default graphs.
> The solution proposed in commit
> #1125477<>and
> #1125652 <> sets the
> basegarph as follows:
> - always trust the content graph
> - for remote resource trust the graph you get by dereferencing the uri
> - for resources in the user-uri space trust that user
> This might not match an intuitive understanding of "authoritative" and I'm
> happy to redefine the issue so that no confusion arises.
> What I do strongly believe is that the proposed patch offers a major and
> very useful new functionality. Especially as it allows the following
> features to be implemented:
> - Thanks to CLEREZZA-544 one can call the render-method to delegate the
> rendering of resources with a UriRef instead of a resource, in this case
> the
> resource is rendered using its own baseGraph rather than the one of the
> calling template. An example usecase for this is rendering the author of a
> comment, the whole profile of the (possibly remote) commenter isn't and
> shall not be part of the baseGraph of the GraphNode returned by the jax-rs
> resource method, yet for rendering the comment-author infobox it might be
> beneficial to render a GarphNode with a baseGraph containing all of the
> information in the users profile-document

I think the described use case is plausible. Besides, I don't see that the
new service
causes changes to any existing API (please correct me if this is wrong)
except adding
new ones, e.g., in CallbackRendererImpl. Thus, existing applications are not
and other or new applications can benefit from the new service.

> - With CLEREZZA-541 the GraphNodeService is accessed from TypeHandler, I
> posted a resolution to this issue because it was already quite there on my
> local machine when Herny reopened CLEREZZA-540, to respect the reopening of
> the issue I didn't mark the dependent issue as resolved. I will of course
> revert the changes if requested to do so by a qualifying -1.
> I'm not arguing that my patches solve all issues one might have around
> getting resource descriptions but I do think it is very valuable and to
> allow to base other stuff on this service I would like the issue to be
> closed. As Henry reopened the issue twice and I don't want to close the
> issue again without a broader discussion. Yet as many thing depend on the
> issue leaving it open doesn't seem an option to me.
> Future enhancement might include:
> - manually force refresh of caches for graphs related to a requested
> resource
> - force an alternative set of baseGraphs to be used (e.g. Only local or
> only
> remote sources)

Just eager to know: will the second enhancement help Henry to solve his
problem that could be solved with the "old" webproxy code?

> So I'm asking you to kindly review the proposed code and vote about closing
> [ ] +1, I agree with accepting the proposed code into trunk
> [ ] 0, I don't care
> [ ] -1, I don't want this code in trunk (must specify a technical
> explanation, please also specify what would have to be changed for the
> patch
> to be acceptable to you)
> Cheers,
> Reto

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message