On 7 Jun 2011, at 20:09, Reto Bachmann-Gmuer wrote:
> [snip a bunch of tit for tat sniping]
>>
>> I did find that very useful in my use case to be able to work without
>> having the content graph appended to the remote graph.
>
> I don't think that's true. Even if you can construct this usecase "tell Dan
> about missing triples" I think you wouldn't even have noticed that you can
> also see properties defined in the content-graph without inspecting the
> GraphNode calling getGraph.
This is where the problem is and why this is taking so long to resolve. You
have an idea of correct architecture that only takes your use cases into
account, and you completely refuse to take other use cases into account,
constantly calling those "bad architectural decisions".
I have use cases where I want to show what someone said remotely, without
merging it with the content graph. Part of this thread tagged "issues of trust"
goes into detail why this is needed.
In your new code you have moved from enabling ssp's to only work with the
information in the GraphNode provided by the JSR311 code, to allowing the SSP
to render a UriRef, by merging information from the web with the content
graph. I wanted to be able to render remote information without merging it with
the content graph, and that is apparently a problem. I am sorry, but that just
sounds completely arbitrary.
> [snip]
>
>>
>> What I am proposing is the creation of more flexible GraphNodes which can
>> have for different
>> applications different logics for dereferencing remote graphs if needed.
>> So instead of your DiscobitsTypeHandler requiring a graphNodeProvider to
>> fetch the remote graphs it could return a new DBContentGraphNode(uri), and
>> that information could be then filled in before reaching the renderlet.
>>
> So you see that what you're questioning is existing infrastructure. I
> strongly disagree that you block development of clerezza trying to enforce a
> redesign of existing code. Make an elaborated proposal and we can discuss
> things. But this is no reason for vetoing changes
But all I am proposing is a way to allow your uses case and the use case that
just does not require the union of the content graph. I don't see how this is
questioning existing infrastructure.
In CLEREZZA-516 "Develop a Foaf Profile Viewer" you are refusing to allow me to
close the issue unless I develop "renderlets for the various classes defined by
foaf" So you are forcing me to use renderlets. Ok. I am willing to try. But if
I then have a use case that requires just the remote content to be shown. I
need to use the renderlet infrastructure that CLEREZZA-540 and co is using. If
I don't you will say I am "questioning existing infrastructure".
So in short your patch here is blocking my CLEREZZA-516 unless we can come to a
compromise solution. Which is what I was looking at doing here.
>>
>> Renderlets could then also create different types of GraphNodes,
>
> Renderlets should not create GraphNodes as they are for rendering
> information not for creating it.
But is that not what you are in effect doing by your new definition of render
that takes a UriRef?
The implementation of your new method render() in CallbackRenderer
public void render(UriRef resource, GraphNode context, String mode,
OutputStream os) throws IOException;
is
public void render(final UriRef resource, GraphNode context, String
mode,
OutputStream os) throws IOException {
final GraphNode resourceNode = AccessController.doPrivileged(
new PrivilegedAction<GraphNode>() {
@Override
public GraphNode run() {
return
graphNodeProvider.get(resource);
}
});
render(resourceNode, context, mode, os);
}
so on line 2 I see the creation of a new GraphNode by using the
GraphNodeProvider. This even can do a web connection.
I am ok, with certain restrictions being placed on what one can do. But I think
the compromise solution could be developed very neatly to cover that. But I
need to know if it is even worth embarking on such a solution without walking
into some invisible "infrastructure walls" that I am not meant to question.
Henry
