I'm missing the magic words "I hereby withdraw my veto against the proposed resolution of CLEREZZA-540" :(
You didn't answer my recent question (asked on 6 Jun 2011, at 18:07). > May I ask you to be explicit: > > [ ] I stick to my -1, but I don't mind the code staying there as long as no > new code is added depending on it > [ ] I want the patch for CLEREZZA-540 reverted > [ ] I withdraw my -1 On Tue, Jun 7, 2011 at 6:31 PM, Henry Story <[email protected]> wrote: > [...] > > I am not sure the difference between the old and the new code lies here at > all. > This looks more at this point like a refactoring. > To a large part yes. > > > As a > > consequence of this the expansion of the resource by a renderlet may or > may > > not be based on the same triples that one would get when dereferencing > the > > linked resource, this is true in the general case for local resources but > > much more for remote resources in which case the renderlet has only > access > > to the triples in the graph underlying the main resource and not the > > description one can get over the web. Currently one has to implement a > root > > resource or a typehandler and add the information of the referenced > resource > > to the graph underlying the graphnode. This is ugly as the added triples > are > > not scoped to the remote resource. > > The above is really difficult to understand. But as I understand there is > the > need in this case to have the content graph union any remote graphs. > See example below, and say what you would return. (.using the current infrastructure). > > > > > Example: At local uri <xy> the user should get a list of articles from > the > > content graph, every article should have a box with information about the > > author. This information should be retrieved from the foaf-profiles of > the > > authors. > > ok, good example. > > (So in the case of the account control panel I am working on we may want to > display a box > of information about each friend...) > > > > > Current bad solution: We make a typehandler or root resource that > generated > > the response for <xy> and we return a graphnode with as underlying graph > the > > union of the content graph and the profile graph of every author. In the > > renderlet (or ssp) we call render passing the GraphNode returned by > > article/foaf:maker as argument. > > > > Solution using the proposed patches: Making a typehandler or root > resource > > is not needed. In the renderlet (or ssp) we call render passing the > UriRef > > returned by article/foaf:maker! as argument. > > ok. And then you get back at each iteration a graph containing the content > graph > union the graph of the user. - Which iteration? You never get back a graph, but always just a graphnode > Those will be different union graphs at each go, and > there may be the type of clashes I described previously: with for example > locally > stored telephone/address/... unioned with the remote telephone/address > etc.. > This is useful sometimes, but one has to be aware of the interplay of local > and > remote information. In my use cases this is sometimes something one wants > to avoid. > Still much better than the status quo, where the clasehs can affect completely unrelated resources. The new kind of union may not be wanted in some cases (youe usecase of telling Dan what is missing in hos profile) while the current situation is a problem in all (or at least a much broader class of) cases, > > > > > > - What's bad with the current solution? > > > > The remote profiles may contain triples about any resource, so the > profile > > could also contain infromation about other information displayed on the > same > > page, e.g. about other authors. > > yes, so because you have a larger union there is more of a risk of a clash. > By reducing the union one can reduce the clash. (Or is there some other > reason here?) > With the patch you might have a co0ntradiction between what the platform takes for granted and what the web takes for granted about a particula author (in the example) without the patch the author A might put information about author B in his profile and this would show up. > > In my applications I was interested in just having the remote profile - ie, > no union at all - because you want to friend someone and see what they say > about themselves before deciding. (though one would also like to know what > other people one knows say about them too - and possible who says what: so > unions won't be that useful, unless they can easily be broken up again) > I think it might be useful to see all the comment a person you're considering to add as friend has left on your instance (or other information in the content graph if there is such information about that person, which if its there it's probably there for a reason). But of course you're free not to use the service. > > > - What's the alternative solution Henry proposes? > > > > At one time there was a package webproxy in the Clerezza trunk. This was > a > > service accessible from Renderlets and ScalaServerPages allowing to > > dereference (or get cached copies) of remote graphs. Using this a > renderlet > > could get a remote graph, locate the resource in it and create a new > > graphnode that could the be passed to the render method. The WebProxy > > service was a major new API introducing a whole bunch of new public > methods > > and a new class for describing resources. > > Look it did its job. What job? It broke up architecture, violated coding and documentation guidelines and fostered abuse of ssp for doing much more than simple presentation. > I never said it was final or fit in with everything else > in ZZ. You did commit it to trunk. Which means the code meets some quality standard and is associated to an issue that is going to be closed very soon. > Nor can I know ahead of time how it fits best into what ZZ does. That's why its good to discuss things and use issue branches. > Your refactoring > here suggests that you yourself don't know ahead of time what is best. Software development is iterative, Yet the acceptance of a new version requires that some standards are met. > Why was the motto: > if you don't like it don't use it NOT applicable there? Because: - The code fit in very badly into the clerezza architecture, it completely unnecessarily introduced new methods and classes design for some future usecases (overarchitecture) - It was lacking documentation - as opposed to here where 5 persons voted in favour of my patch I don't think anybody reviewing the code (but maybe you) would have voted +1 - it did much more than the issue claimed to do, for example it renamed graphs > Why not just enter a new issue to refactor it to something better? Because it was a degradation of the code. > Then at least you would have allowed me to close an issue, > See the reviwing guidelines I linked previously > and acknowledge my contribution, and then we could discuss the pros and > cons of new ways > of doing things. ANYWAY... > I achnoledge that you're upset. > > > This new service did not integrate > > with TcManager and was using platform services despite being an > SCB-bundle. > > The Bundle was removed after having been in large parts obsoleted by > > rdf.storage.web and after creating problems with a graph-renaming it > > introduced. > > ? Ah the problem of graph renaming it "introduced" was an improvement over > an existing graph renaming problem you yourself have acknowledged and which > I told you about when I helped you add WebID to Clerezza last summer. No. > Naming remote resources by appending ".cache" was clearly not good. It > fixed that problem, but you thought you could do better. Ok, but why not > acknowledge that I introduced a fix, rather than putting it in terms of me > introducing a bug. > The ".cache" was obviously bad, your fix was imho worse. > > There followed then a discussion on graph naming, where you put forward > another fix to the ".cache" problem. There was a discussion there too, but > let's get along with life... > Yes, there too there was a -1 from you. And it was hard to make you understand that vetoing my proposol doesn't mean your proposal is automatically accepted but that it would mean to go back to the status quo ante (i.e. the last versionaccepted by silent consensus) with was the ugly but workable ".cache"-solution. > > 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. > In your use case that may be different, but if you remove my option and > force me to use yours then don't then argue that I don't need to use your > code!!!!! > So we're back to your webproxy. If you really think its good enough to be part of trunk call for a vote on the patches one sees here: https://issues.apache.org/jira/browse/CLEREZZA-463?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs > > In any case THAT IS NOT THE ALTERNATIVE SOLUTION I PROPOSED recently on > this thread. > In fact it was an attempt of a benevolent interpretation of your opposition. > > Wwhat 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 > > Renderlets could then also create different types of GraphNodes, Renderlets should not create GraphNodes as they are for rendering information not for creating it. Reto > for example a RemoteGraphNode(uri) for my use case, and a > ContentGraphNode(uri) for your use case, and others for yet other use cases. > (eg, one that finds just what MY friends think about someone) They would be > easy to create, and we could all try out different methods of filling this > out. > > I am not 100% sure of this of course, but as a first suggestion something > like that looks like it could help us both, and perhaps even make code a lot > more readable. > > > > > [...] > > > >> > >> The problem with this is that the trust decisions made by the > >> GraphNodeProvider are now hidden in the very > >> complex decision procedure to be found in its code, which depends on yet > >> other Providers which themselves are > >> not clear. These functions will be hidden to the programmer returning a > >> UriRef from the JSR311 code. > >> > >> The point of the compromise solution is rather to help make these > decisions > >> transparently clear. It would be much better to create declaratively > typed > >> GraphNode objects with different and clearly defined behaviours. But > here > >> the whole rendering engine is pushed to make a pretty arbitrary choice > on > >> what is to be trusted. This does not need to be the case. > >> We can do better. > >> > >> In any case I don't remember reading a good defence of why suddenly > these > >> changes are needed. > >> > > > > It seems you're not reading my replies very carefully. Despite me > correcting > > you twice you're still talking about JSR311 returning UriRefs, for the > whole > > renderlet/ssp mechanism to be used a JaxRs (aka jsr311) resource method > > returns a GraphNode. > > Ok, so you are having SSP code call do rendering on URIs. > > > With pre-540 DiscobitsTypeHandler this was only based > > on the content-graph. You're opposing to this patch which also adds the > > remote graph for remote resources but you don't specify what the > underlying > > graph should be. > > I am just saying that there are many cases here, and we can be flexible > about > how this works out. > > > > > > Reto > > > > > > > >> > >> Henry > >> > >> > >>> > >>> > >>> > >>>> > >>>> I don't think that the patch henry vetoed has anything bad in it, or > >> brings > >>>> something one has to compensate for. If the platform is asked "tell me > >>>> about > >>>> xy" it tells what the platform takes for reasoanbly granted, that is > by > >>>> default what it get from an authoritative description on the weeb and > >> from > >>>> the public part of its own trusted data. > >>>> > >>> > >>> right, I agree with you and I am still +1 to the proposed patch, sorry > if > >> I > >>> wasn't clear enough. > >>> Tommaso > >> > >> Social Web Architect > >> http://bblfish.net/ > >> > >> > > Social Web Architect > http://bblfish.net/ > >
