<div class="gmail_quote">On Wed, Feb 10, 2010 at 1:12 PM, Kenton Varda <span dir="ltr"><<a href="mailto:temporal@gmail.com">temporal@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>Misc comments:</div><div><br></div><div><div>- How is registering a provider initiated? Hopefully we don't just pop up a dialog box on the web site's whim. I have been imagining that the site would provide some sort of a widget which represents the object, and the user must click on that in order to initiate the provider registration process. Similarly, the requester site would have some sort of widget representing a "socket" for an object, and the user would click on it in order to initiate the process of fulfilling the request.</div>
</div></span></div></blockquote><div><br>Yes, the widget would be a DOM element, implemented by the browser and rendered as a button.<br>
<br>
For requesting a service, we can use <input> with a new "type" attribute value, or use "type=file" so that it falls back to file upload on browsers without powerbox support.<br>
<br>
For registering a provider, <input> is not appropriate. <input> works for file upload but there is no equivalent for file download, so I think
we'd want a new element, but I'm not sure what to call it. Probably
not "<output>". ;-)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>
<div>We should provide Javascript libraries implementing these widgets -- maybe the scripts would actually be hosted by the powerbox server?</div></div></span></div></blockquote><div><br>I'm not sure what you mean here. If the widgets aren't implemented by the browser (in the ideal case, not a prototype), what would a library implement?<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>
<div></div></div><div>- In addition to the UI you describe, we should support drag-and-drop direct from a provider site to a requester site. As with drag-and-drop for opening files, power users will find this more convenient than going through "save" and "open" dialogs. This is straightforward to implement if the provider and requester use widgets like I described in the previous point.</div>
</span></div></blockquote><div><br>I was thinking that the request-service and register-provider buttons could be overloaded so that not only can you click on them to open a dialog, you can also drag-and-drop one onto the other to perform a grant.<br>
<br>This would work fine for non-interactive providers.<br><br>I am not so sure about interactive providers. We could open a new tab after the drag-and-drop, but this seems like it would be disorienting. There is some precedent for requiring further interaction after a drag-and-drop: on Windows, right-button-dragging a file opens a menu to choose between Copy, Move and Create Shortcut. However, that is only a small menu.<br>
<br>I must say I have a hard time imagining how cross-tab drag-and-drop can be made easy-to-use. Wouldn't the user have to arrange two browser windows side by side? Or would the browser provide a shortcut to open two tabs side by side in the same window? I don't think I've ever used drag-and-drop between browser tabs. The last GUI I used that used drag-and-drop extensively like this was RISC OS.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">
<div></div><div>- The powerbox should provide a UI for visualizing all established connections between requesters and providers, showing activity occurring on these connections, and allowing the user to revoke connections.</div>
</span></div></blockquote><div><br>In my proposal the browser/powerbox does not mediate the connections, so it cannot show activity on those connections. In fact, it cannot enforce mediation, because the two parties involved have network access and can arrange to bypass any mediation.<br>
<br>So it's up to the provider to offer a review and revocation facility, which can be reached via its info_url. I think this is more useful than putting a revocation facility into the browser/powerbox, because the provider can display the information in the form that is most appropriate to the service it provides. If a provider doesn't offer revocation, it's possible to wrap it to make a provider that does.<br>
<br>That said, it may be useful for some services to voluntarily be mediated through the browser/powerbox, so that they can be revoked automatically when the tab is closed, e.g. for tab-lifetime-limited camera access.<br>
<br>Also, the powerbox can keep a log of all the grants it has established, even if it can't revoke them itself.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">
<div></div><div>- Maybe type names should be identified by URLs of type definitions.</div></span></div></blockquote><div><br>Maybe. The main question I have is whether we should attempt to display service types to the user, to help them understand how provider filtering works.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>
</div><div>- Obtaining the site's powerbox web key: This is so that we can force default pet names to begin with the site's domain name, right?</div></span></div></blockquote><div><br>Yes.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>This sounds like a case of the site having ambient authority, which ironically means CORS could provide the answer: the site could make a CORS request to the powerbox to get the web key, and the powerbox would use Access-Control-Allow-Origin to ensure that a site can only obtain its own key.</div>
</span></div></blockquote><div><br>Yes, that could work for a prototype. The site would need a way to discover the (guessable) URL of the powerbox server; the URL could be stashed in the DOM using Greasemonkey.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><div>
This shouldn't be a long-term solution, of course, because we'd ideally want to avoid relying on CORS in any way.</div></span></div></blockquote><div><br>Yes, the long-term solution is a DOM element.<br><br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">
<div></div><div>- Do we need to require provider URLs to be unguessable? What if the service being provided is really intended to be accessible to all? How about we don't make any particular requirements on the provider URLs, but suggest that they should be web keys if the resource is intended to be private.</div>
</span></div></blockquote><div><br>That sounds fine. I wasn't going to suggest that anyone other the URL's creator checks that the URL is sufficiently random. I don't know if there is a way to do this anyway.<br>
<br>There may well be public services, e.g. a public web cam that provides the same API as a local web cam.<br><br>There might also be public, shared provider web-keys which generate new, private service web-keys every time they are invoked. I can't think of a good example at the moment though. (The list() constructor in Python, which creates a mutable list, is an example in a programming languages context, but this does not create revocable objects.)<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">
<div></div><div>- Are grants revoked automatically when the requester site is closed? I'd argue that this is usually -- but not always -- desirable.</div></span></div></blockquote><div><br>See my comments above.<br>
</div>Cheers,<br>Mark<br><br></div>