incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: 540 in perspective -- Re: [VOTE] Accept the proposed patch of CLEREZZA-540
Date Wed, 08 Jun 2011 12:21:29 GMT
2011/6/8 Reto Bachmann-Gmuer <reto@apache.org>

> 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 <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