On 8 Jun 2011, at 13:02, Reto Bachmann-Gmuer wrote:
> Dear Henry,
>
> The current situation is really annoying and part of the blame goes on me as
> I'm part of the Clerezza community that failed to introduce you to the
> project and the community in a way that empowers you to identify issues
> suitable for an iterative development that leads to the envisaged viral
> social web platform and to provide resolutions for these issues capable of
> consensus.
>
> The current is the worst crises of our community and the biggest impediment
> to productive work we have had till now. So I urge to collaborate with the
> following approach to get back to productive work (i.e. getting issues closed
> rather than arguing):
>
> - you withdraw your -1 against a patch that doesn't change the behaviour of
> any existing method and which has had 5 +1
>
> - I will give hand to find ways to identify useful issues and solutions for
> the desired functionality. You specify the issue you'd like to address and
> I'll help you split this up into actually resolvable (and reviewable) issues
> and describe approaches on how this be resolved. Then you'll be able to
> contribute to a monotonic growth of closed (tiny) issues and thus to a
> constant improvement of clerezza.
>
> Please Henry, help leaving the current mess behind and get back to a
> collaboration that yields to product improvements.
Ok, sounds good. +1
Sorry for the discussion getting over heated a bit. I was probably under too
much pressure with all these things going on to think clearly enough to get to
the core of the problem in one step. But it's all to the good: I did learn a
lot about ZZ in the process of this conversation, and we worked out some
interesting issues. Remember that we are having this conversation now. All the
other copy cats will have to go through a similar process and discussion, but
without our background, each such conversation will be a place to make the
wrong decision. Let us try to keep the system as open as possible, as we don't
know all the ways to make decisions ahead of time.
From Berlin,
Henry
>
> Cheers,
> Reto
>
> On Wed, Jun 8, 2011 at 12:24 PM, Henry Story <[email protected]> wrote:
>
> 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
>
>
Social Web Architect
http://bblfish.net/
