incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <r...@apache.org>
Subject Re: 540 in perspective -- Re: [VOTE] Accept the proposed patch of CLEREZZA-540
Date Wed, 08 Jun 2011 11:02:18 GMT
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.

Cheers,
Reto

On Wed, Jun 8, 2011 at 12:24 PM, Henry Story <henry.story@bblfish.net>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
>
>

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