Re: Joins on capabilities that have passed through different membranes
Marc Stiegler <[email protected]> Tue, 5 Jan 2016 19:20:23 -0700
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAK=cCVV-ihJBgTL3yWbAg9_BLrD2x_NS4_dBt910=q961j0B_w@mail.gmail.com> |
--===============4247287893435085800== Content-Type: multipart/alternative; boundary=001a113d3b5e1938b80528a0ff71 --001a113d3b5e1938b80528a0ff71 Content-Type: text/plain; charset=UTF-8 "Humans, meanwhile, are much worse at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining capabilities when they land in a human's capability store." So, I keep on pressing people to think of capabilities as being like documents, and managing them as documents, which is very simple and easy to do with webkeys that are dragged and dropped onto the desktop from the browser and auto-converted into shortcut docs. Consider the following example: Carol is working with Alice on project A, and with Bob on project B. Both project A and B involve using document D. So: Carol has all her project A docs in folder ProjA, and her project B docs in folder projB. Alice sends Carol a webkey for D. Carol drops it into folder projA. When working on A, Carol clicks the webkey in projA. Bob sends Carol a webkey for D. Carol drops it into folder projB. When working on B, Carol clicks the webkey in projB. It never makes a difference to Carol whether the cap for A and the cap for B are pointing at the same document or not: they might be pointing at variations of D that are intended to be merged another day, Carol does not care! She uses the correct cap in the correct context, and it just works right. Humanity solved the problem of managing caps when Xerox invented the desktop metaphor for document organization, because we already have the facility to make caps behave as docs. We just have to recognize that this problem is solved, and use the solution. --marcs On Tue, Jan 5, 2016 at 5:05 PM, Matt Rice <[email protected]> wrote: > I'm not sure its something normal users would want to work with, but > Personally, I think it'd be nice to view the current applications > capabilities > in the context of my directory structure... > > Mac OSX has a 'proxy icon', thing, from the setRepresentedFilename: > method on a window, that can be dragged around to various > applications... > > > http://stackoverflow.com/questions/21101562/how-to-have-multiple-proxy-icons-in-cocoa-document-windows > > I'd prefer something where similar but where click on the proxy icon, > sends the windows capabilties to something like the shelf in: > > > http://debian.uni-duisburg-essen.de/misc/GNUstep/Docs/SystemOverview/pictures/workspace.png > > I could then select the thing on the shelf to view it within the > context of what is labeled the viewing area (where presumably i would > have a RW capability sitting nearby).. > > The shelf, was typically used both as a place to put commonly used > things, and as a scratch space for temporary usage, I think this usage > requires to keep those two functions separate by some means, > > so a shelf area for the capabilities from the window, and a shelf area > for commonly used stuff, this commonly used area would also see usage > as a scratch area when I want to do something with the capabilities > from more than one window... > > worth considering what I recall has been said is that keykos had some > fairly long lived capabilities, is it presumed that the [rodoc] > received is the most recent and synchronized whenever I edit [rwdoc], > or some ancient version where a newer one may already has the > requested change... > I think its worthwhile to be able to do a reality check, before just > editing... > I'm not sure it isn't even applicable in those cases we can generally > assume a synchronized copy could exist in writer -> editor -> publish > scenerios, you generally want to speak about a very specific version > of a capability when it comes time publish. > > > On Tue, Jan 5, 2016 at 8:24 AM, <[email protected]> wrote: > > > > On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <[email protected]> wrote: > >>> > >>> Can you provide a concrete example of why one would want to perform the > >>> join instead of just using the two capabilities separately? > > > > > > I'm going to take a guess. This is a problem we talked about extensively > > during the early parts of the Caja project, and discussed with our > security > > PMs. From what I recall, we did not have a good answer. > > > > * Let's say I have a document I own and have read/write access to. Let's > > call my capability to it [rwdoc]. > > > > * I share a read-only cap to that document with Kenton. I say something > > like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. Regards." > > > > * Months later, Kenton replies to me, saying, "Hey Ihab, I think you > need to > > add the following information to [rodoc], because some new stuff came up! > > Kthxbai." > > > > * The cap [rodoc] arrives in my user agent -- browser or whatever. Now > what? > > There is no simple "correct" solution. > > > > -> If my user agent automatically amplifies it to [rwdoc], that means the > > agent has ambient authority. In fact, that's what happens with browsers > and > > cookies today! And when you make the situation a bit more complex, with > > Kenton's original example, you end up with the joining problem he has > > raised. > > > > -> If my user agent does nothing, then I have "two ways" to get to one > > logical document, and we don't know how to explain this state of affairs > to > > end-users. > > > > I think this is a UX research problem. :) > > > > Ihab > > > > -- > > Ihab A.B. Awad, Palo Alto, CA > > > > _______________________________________________ > > cap-talk mailing list > > [email protected] > > http://www.eros-os.org/mailman/listinfo/cap-talk > > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > --001a113d3b5e1938b80528a0ff71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div><div><div>"Humans, meanwhile, are= much worse=20 at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining=20 capabilities when they land in a human's capability store."<br><br= ><br></div>So, I keep on pressing people to think of capabilities as being = like documents, and managing them as documents, which is very simple and ea= sy to do with webkeys that are dragged and dropped onto the desktop from th= e browser and auto-converted into shortcut docs.<br><br></div>Consider the = following example: Carol is working with Alice on project A, and with Bob o= n project B. Both project A and B involve using document D. So:<br><br></di= v><div>Carol has all her project A docs in folder ProjA, and her project B = docs in folder projB.<br><br></div>Alice sends Carol a webkey for D. Carol = drops it into folder projA. When working on A, Carol clicks the webkey in p= rojA.<br><br></div>Bob sends Carol a webkey for D. Carol drops it into fold= er projB. When working on B, Carol clicks the webkey in projB.<br><br></div= ><div>It never makes a difference to Carol whether the cap for A and the ca= p for B are pointing at the same document or not: they might be pointing at= variations of D that are intended to be merged another day, Carol does not= care! She uses the correct cap in the correct context, and it just works r= ight.<br><br></div>Humanity solved the problem of managing caps when Xerox = invented the desktop metaphor for document organization, because we already= have the facility to make caps behave as docs. We just have to recognize t= hat this problem is solved, and use the solution.<br><br></div>--marcs <spa= n class=3D"im"></span></div><div class=3D"gmail_extra"><br><div class=3D"gm= ail_quote">On Tue, Jan 5, 2016 at 5:05 PM, Matt Rice <span dir=3D"ltr"><= <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= >></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure its = something normal users would want to work with, but<br> Personally, I think it'd be nice to view the current applications capab= ilities<br> in the context of my directory structure...<br> <br> Mac OSX has a 'proxy icon', thing, from the setRepresentedFilename:= <br> method on a window, that can be dragged around to various<br> applications...<br> <br> <a href=3D"http://stackoverflow.com/questions/21101562/how-to-have-multiple= -proxy-icons-in-cocoa-document-windows" rel=3D"noreferrer" target=3D"_blank= ">http://stackoverflow.com/questions/21101562/how-to-have-multiple-proxy-ic= ons-in-cocoa-document-windows</a><br> <br> I'd prefer something where similar but where=C2=A0 click on the proxy i= con,<br> sends the windows capabilties to something like the shelf in:<br> <br> <a href=3D"http://debian.uni-duisburg-essen.de/misc/GNUstep/Docs/SystemOver= view/pictures/workspace.png" rel=3D"noreferrer" target=3D"_blank">http://de= bian.uni-duisburg-essen.de/misc/GNUstep/Docs/SystemOverview/pictures/worksp= ace.png</a><br> <br> I could then select the thing on the shelf to view it within the<br> context of what is labeled the viewing area (where presumably i would<br> have a RW capability sitting nearby)..<br> <br> The shelf, was typically used both as a place to put commonly used<br> things, and as a scratch space for temporary usage, I think this usage<br> requires to keep those two functions separate by some means,<br> <br> so a shelf area for the capabilities from the window, and a shelf area<br> for commonly used stuff, this commonly used area would also see usage<br> as a scratch area when I want to do something with the capabilities<br> from more than one window...<br> <br> worth considering what I recall has been said is that keykos had some<br> fairly long lived capabilities, is it presumed that the [rodoc]<br> received is the most recent and synchronized whenever I edit [rwdoc],<br> or some ancient version where a newer one may already has the<br> requested change...<br> I think its worthwhile to be able to do a reality check, before just editin= g...<br> I'm not sure it isn't even applicable in those cases we can general= ly<br> assume a synchronized copy could exist in writer -> editor -> publish= <br> scenerios, you generally want to speak about a very specific version<br> of a capability when it comes time publish.<br> <span class=3D"im HOEnZb"><br> <br> On Tue, Jan 5, 2016 at 8:24 AM,=C2=A0 <<a href=3D"mailto:ihab.awad@gmail= .com">[email protected]</a>> wrote:<br> ><br> </span><div class=3D"HOEnZb"><div class=3D"h5">> On Tue, Jan 5, 2016 at = 4:41 AM, David Bruant <<a href=3D"mailto:[email protected]">bruant.d@gm= ail.com</a>> wrote:<br> >>><br> >>> Can you provide a concrete example of why one would want to pe= rform the<br> >>> join instead of just using the two capabilities separately?<br= > ><br> ><br> > I'm going to take a guess. This is a problem we talked about exten= sively<br> > during the early parts of the Caja project, and discussed with our sec= urity<br> > PMs. From what I recall, we did not have a good answer.<br> ><br> > * Let's say I have a document I own and have read/write access to.= Let's<br> > call my capability to it [rwdoc].<br> ><br> > * I share a read-only cap to that document with Kenton. I say somethin= g<br> > like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. Re= gards."<br> ><br> > * Months later, Kenton replies to me, saying, "Hey Ihab, I think = you need to<br> > add the following information to [rodoc], because some new stuff came = up!<br> > Kthxbai."<br> ><br> > * The cap [rodoc] arrives in my user agent -- browser or whatever. Now= what?<br> > There is no simple "correct" solution.<br> ><br> > -> If my user agent automatically amplifies it to [rwdoc], that mea= ns the<br> > agent has ambient authority. In fact, that's what happens with bro= wsers and<br> > cookies today! And when you make the situation a bit more complex, wit= h<br> > Kenton's original example, you end up with the joining problem he = has<br> > raised.<br> ><br> > -> If my user agent does nothing, then I have "two ways" = to get to one<br> > logical document, and we don't know how to explain this state of a= ffairs to<br> > end-users.<br> ><br> > I think this is a UX research problem. :)<br> ><br> > Ihab<br> ><br> > --<br> > Ihab A.B. Awad, Palo Alto, CA<br> ><br> </div></div><div class=3D"HOEnZb"><div class=3D"h5">> __________________= _____________________________<br> > cap-talk mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]= </a><br> > <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"no= referrer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-tal= k</a><br> ><br> _______________________________________________<br> cap-talk mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><= br> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer= rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>= <br> </div></div></blockquote></div><br></div> --001a113d3b5e1938b80528a0ff71-- --===============4247287893435085800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk --===============4247287893435085800==--