<div class="gmail_quote">On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <span dir="ltr">&lt;<a href="mailto:oliver@apple.com">oliver@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im">It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need.  Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use.</div>
</div></div></blockquote><div><br></div><div>This is an aside that concerns the general point above, not GlobalScript etc. specifically.</div><div><br></div><div>I agree that in general we should push complexity towards the UA vendor and away from the web author, but your statement is too sweeping.  It is certainly relevant to consider the concept of multiprocess browsers when designing APIs.  Failing to take that into account at all can lead to APIs which make process separation outright impossible.  It&#39;s one thing to make implementation somewhat trickier for UA vendors, it&#39;s another thing entirely to completely eliminate whole categories of browser architectures in the name of developer simplicity.</div>
<div><br></div><div>To give an example of &quot;poor foresight in a spec&quot; from the past, synchronous XHR is convenient for developers in certain circumstances, but I think all implementors recognize that it was a mistake to specify and we&#39;d be better off without it.  For a ridiculous hypothetical example, we wouldn&#39;t spec an API that required UAs to solve the halting problem.  Developer need and convenience should certainly be the prime motivator of APIs, but not the only motivator.</div>
<div><br></div><div>PK</div></div>