2011/6/8 Reto Bachmann-Gmuer <[email protected]> > 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. >
I'd also be very happy to jump in and help with identifying and solving possible issues with this. > > Please Henry, help leaving the current mess behind and get back to a > collaboration that yields to product improvements. > > Regards, Tommaso > 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 > > > > >
