incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: don't use it if you don't need it -- Re: [VOTE] Accept the proposed patch of CLEREZZA-540
Date Mon, 06 Jun 2011 14:03:36 GMT
- What problem does CLEREZZA-544 address?

Without the proposed patches for 540 and its dependencies the discobits
typehandler returns the requested resource as GraphNode from the
content-graph. This resource may have properties pointing to other
resources. When one accesses that resource as RDF it gets the MSG with
recursively the MSG of resources that only differ in their names by a
fragment identifier added to the name of the graph-node resource. As a
consequence of this the expansion of the resource by a renderlet may or may
not be based on the same triples that one would get when dereferencing the
linked resource, this is true in the general case for local resources but
much more for remote resources in which case the renderlet has only access
to the triples in the graph underlying the main resource and not the
description one can get over the web. Currently one has to implement a root
resource or a typehandler and add the information of the referenced resource
to the graph underlying the graphnode. This is ugly as the added triples are
not scoped to the remote resource.

Example: At local uri <xy> the user should get a list of articles from the
content graph, every article should have a box with information about the
author. This information should be retrieved from the foaf-profiles of the

Current bad solution: We make a typehandler or root resource that generated
the response for <xy> and we return a graphnode with as underlying graph the
union of the content graph and the profile graph of every author. In the
renderlet (or ssp) we call render passing the GraphNode returned by
article/foaf:maker as argument.

Solution using the proposed patches: Making a typehandler or root resource
is not needed. In the renderlet (or ssp) we call render passing the UriRef
returned by article/foaf:maker! as argument.

- What's bad with the current solution?

The remote profiles may contain triples about any resource, so the profile
could also contain infromation about other information displayed on the same
page, e.g. about other authors.

- What's the alternative solution Henry proposes?

At one time there was a package webproxy in the Clerezza trunk. This was a
service accessible from Renderlets and ScalaServerPages allowing to
dereference (or get cached copies) of remote graphs. Using this a renderlet
could get a remote graph, locate the resource in it and create a new
graphnode that could the be passed to the render method. The WebProxy
service was a major new API introducing a whole bunch of new public methods
and a new class for describing resources. This new service did not integrate
with TcManager and was using platform services despite being an SCB-bundle.
The Bundle was removed after having been in large parts obsoleted by and after creating problems with a graph-renaming it


> The problem with this is that the trust decisions made by the
> GraphNodeProvider are now hidden in the very
> complex decision procedure to be found in its code, which depends on yet
> other Providers which themselves are
> not clear. These functions will be hidden to the programmer returning a
> UriRef from the JSR311 code.
> The point of the compromise solution is rather to help make these decisions
> transparently clear. It would be much better to create declaratively typed
> GraphNode objects with different and clearly defined behaviours. But here
> the whole rendering engine is pushed to make a pretty arbitrary choice on
> what is to be trusted. This does not need to be the case.
> We can do better.
> In any case I don't remember reading a good defence of why suddenly these
> changes are needed.

It seems you're not reading my replies very carefully. Despite me correcting
you twice you're still talking about JSR311 returning UriRefs, for the whole
renderlet/ssp mechanism to be used a JaxRs (aka jsr311) resource method
returns a GraphNode. With pre-540 DiscobitsTypeHandler this was only based
on the content-graph. You're opposing to this patch which also adds the
remote graph for remote resources but you don't specify what the underlying
graph should be.


> Henry
> >
> >
> >
> >>
> >> I don't think that the patch henry vetoed has anything bad in it, or
> brings
> >> something one has to compensate for. If the platform is asked "tell me
> >> about
> >> xy" it tells what the platform takes for reasoanbly granted, that is by
> >> default what it get from an authoritative description on the weeb and
> from
> >> the public part of its own trusted data.
> >>
> >
> > right, I agree with you and I am still +1 to the proposed patch, sorry if
> I
> > wasn't clear enough.
> > Tommaso
> Social Web Architect

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