On Thu, Jun 2, 2011 at 10:33 AM, <[email protected]> wrote: > A lot harder than this fix. In what situation would we use more than > one?
When we want to run multiple taming frames to establish independent module contexts. In other words, our system is by design not a per-host-frame singleton. For example, while using gadgets from distinct sources which may have a different interpretation of what "jquery.js" should be -- like different versions of the same library. There are two actual use cases: (a) It allows Caja to be more of a feature-complete in-page "operating system" supporting multiple independent contexts; but, more practically: (b) It provides an "exit hatch" for any thorny unforeseen problem -- in testing or production -- that can be solved by just creating "two of everything" and being done with it. :) The question of whether this is *necessary* is a good one. We've talked about it before, but I don't think we've come to a conclusion yet. I think the reason is that, beyond abstract API issues (do you call caja.configure and return a frameGroup, or do you just configure globally, etc etc), our hand has yet to be forced. How hard *is* it really to preserve the non-singleton nature? Could we come up with a quick little sketch of the simplest possible non-singleton solution and evaluate it? Ihab -- Ihab A.B. Awad, Palo Alto, CA
