This is such an inversion of the "CGI" paradigm [in the client side though],
where CGI scripts got run over by multi-threaded server side processing in
the lines of servlet/JSP.
Server: Multi-threaded processing for each request
Client: Multi-process for each domain
>From what I can recall in terms of the browser dictating the way UI needs
to respond to, I would really like to leave tasks like "pasting a URL into
an editor window" to behave as intended, rather than overridden by the
browser by smartly adding "<a></a>" tags around it. A lot of this is visible
within M$ applications, where the default behavior irks the hell out of me
when I do not want URL's to be wrapped into a link.
I have been using Chrome to test out applications that we write in our
company and all appears fine as yet :) Will have to wait for the non-beta
though. I really wish that the existing JS libraries do not have to add yet
another indirection of the type "if(isChrome) { . . . }". That would make
the code yucky, as already it is.
Regards
Amarjeet
On Fri, Sep 12, 2008 at 8:12 PM, Casper Bang <[EMAIL PROTECTED]> wrote:
>
> Wow, that's an unusual hybrid behavior, arguably an optimization that
> benefits Google sites themselves by avoiding process setup overhead.
> In contrast, IE8 has true one-process-per-page semantics regardless of
> top-level domain.
>
> It would be interesting if you could somehow teach the browser which
> pages to share in one process and which to host in an individual
> process. Perhaps even by some heuristics/characteristics, say sites
> who earned your trust somehow. I'm sure lots of people are like me,
> with 10+ tabs open constantly we don't necessarily all want to be
> spawned as individual processes.
>
> /Casper
>
>
> On Sep 12, 3:45 pm, ndluthier <[EMAIL PROTECTED]> wrote:
> > One of the concerns expressed in episode #204 was that Google Chrome
> > made UI decisions based on internal implementation. The concern was
> > that by having a seperate process (an internal implementation detail)
> > for each tab (a UI representation), the internal implementation was
> > dictating design decisions.
> >
> > The Chromium blog explains the multi-process architecture in more
> > detail athttp://
> blog.chromium.org/2008/09/multi-process-architecture.html.
> > They create a new process for each *registered domain name*, not for
> > each tab. If two tabs are viewing pages on the same top-level domain,
> > they will share the same process.
> >
> > This is definitely not expressed correctly in the comic. The comic
> > does explain that different sites use different processes, but also
> > says that tabs run in different processes. The blog entry clarifies
> > the actual implementation.
> >
> > Interestingly, the sandboxing based on top-level domain is a bit
> > unfortunate (maybe), considering that Google Maps, Docs, Calendar,
> > Groups, and Gmail are all on the same domain. Based on the blog post,
> > there would be one process to rule them all.
> >
>
--
Amarjeet Singh
Phone: +91-98712-76661
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
