On 7/1/07, <b class="gmail_sendername">Andy Palay</b> <<a href="mailto:ajpalay@google.com">ajpalay@google.com</a>> wrote:<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><div>As for the burden to put apps in their own domain -  First it seems to be an unnecessary requirement. I build an app, I choose a URL as I normally would and I would hope everthing would work out fine. Second it doesn't work well for environments where access to the domain is not possible. Consider the case of internal corporate apps. People post new web apps using their 'individual' internal corporate web server. They can choose whatever name they want. What they don't have is access to the domain in order to do this.  I grant that this scenario is currently not well supported by the Gear's security model (something that I believe will need to change), but it is a real use of technology.
</div></div></blockquote><div><br>I'm not really sure what this scenario entails, perhaps because I don't know what you mean by "individual internal corporate web server" ... can you be more specific?<br>
</div><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 class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>If it is, then I would suggest simply allowing consistency to be partitioned by directory as well. I'm not sure of the best way for the server to configure that, though.
<br></div><div></div></div></blockquote></span><div><br>I'm still not sure why not have consistency enforced at the application level. This way an application can pull code from whereever it needs to regardless of the directory structure. 
</div></div></blockquote><div><br>Because it's more complex: we need new APIs to define what an application boundary is, those APIs have to be interoperably implemented, and we have to make sure that overlapping boundaries are not allowed, or if they are allowed, we have to define how that overlap is handled in a sensible way. We've already seen an unanticipated problem arise because a manifest update can create overlap.
<br><br>I appreciate that providing flexibility to application developers is a good thing. But reducing complexity is also a good thing, for implementors and actually for application developers too. This is the tradeoff we must wrestle with.
<br><br>(I quite like my X-Consistency-Group suggestion because it can be ignored by Web authors and/or browser implementors without breaking anything, and by design it cannot lead to overlapping consistency boundaries.)<br>
<br>Rob<br></div></div>-- <br>"Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more?" Simon replied, "I suppose the one who had the bigger debt canceled." "You have judged correctly," Jesus said. [Luke 7:41-43]