incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <>
Subject Re: 540 in perspective -- Re: [VOTE] Accept the proposed patch of CLEREZZA-540
Date Wed, 08 Jun 2011 14:41:26 GMT

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,


> Cheers,
> Reto
> On Wed, Jun 8, 2011 at 12:24 PM, Henry Story <> 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

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