Use tha mialing lits for questions you encourage a broad discussiuon, post a question-issue if you just would like to have an answer. I appreciate brain-storming issues, but here its about changes in the code. You're recent renaming of graphs caused some problems (e.g. my wall application no longer worked), so I wanted to try to get a consuns on the name to choose. Now I have you -1 but no alternative proposal.
Reto On Fri, May 13, 2011 at 2:37 PM, Henry Story <[email protected]> wrote: > Why are you having this debate on the mailing list? There are a number of > bug reports where > this issue has already been discussed? > For example: > https://issues.apache.org/jira/browse/CLEREZZA-489 > And there were a number of other bugs that are duplicates of it: > CLEREZZA-470 and CLEREZZA-463. > I just want to know when we are meant to use the mailing list and when the > issue > database. > > > > On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote: > > ----- Original message ----- >> >> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote: >> >> > >> > For cached graphs I suggest to have uirs like: >> > >> > urn:x-localinstance:/cache/<remote-uri> >> >> -1 >> >> Should each user who makes a request not get a different remote graph? > > No, this would increase complexity too much. What is in the cache depens > solely on the platform instance. If a user want to retrieve something with > her identity she cannot use webproxy. > > > > >> Because what if a remote instance returns different graphs to different >> users for the same resource? >> >> Btw, I also opened this discussion in CLEREZZA-489 [1] >> >> My guess is that the graph management should hide all of this from the >> user. >> >> The user should ask for relative graphs if he wants local ones. > Which is a direct access to the cache graph, which is consitent with my > proposal above. > >> >> Then if he wants remote graphs he should use the name of the remote >> graph he wishes to get. How that remote graph is named interally is not >> really important. > Which somehow contrasts your -1 above. > >> If the fetch is done over TCP without cookies or >> headers, then presumably all users of the server can view that graph >> equally. If fetching the remote graph requires authentication, then the >> graph will be in part determined by who fetched it. >> >> In the end these graphs should probably just be blank nodes, with >> descriptors of how they were fetched. > Yes, i a perfect world we have bracketing rdf stores so that graphs can be > anonymously within others. But till then we need a key (name) for our named > graph store. > > If you want to stick to your -1, could you popose an alternative? > > I really want to do some tidying in the proxy code. > > Cheers, > reto >> >> Henry >> >> [1] https://issues.apache.org/jira/browse/ >> >> Social Web Architect >> http://bblfish.net/ >> > > > Social Web Architect > http://bblfish.net/ >
