63925 - [RFE] enable Necko to run as a separate app.

Status: VERIFIED INVALID

(Core :: Networking, enhancement)

Description

[timeless]

spun off from bug 40109 [RFE] Ability to start two instances of mozilla.

This is a request that a version of netwerk be designed so that it can run as a 
separate process, ala PSM.

If netwerk could run as a separate app, then two instances of mozilla could 
share a netwerk app and presumably safely share a cache directory.

Other bugs will be filed. Please don't mark this as wontfix w/o expressing your 
opinion in blocked bugs.

This bug is filed as All/All. Please treat it as a meta status bug for the 
various os implementations if necessary.

Extra considerations: MultiUser and MultiSession
[eg: w2k terminal services, unix].

Nothing is safe, nor is anything sacred. A mozilla session will probably have 
to find all necko instances and ask each of them if they are capable of 
helping or if they own the cache directory.

case 0. aka 'Simple Case'
User runs mozilla. Mozilla runs necko-chrome and then checks for a necko 
managing the user's cache directory. It doesn't find one and spawns a 
necko-user to manage the directory.  Mozilla says hi to necko and the User gets 
to use mozilla.

Possible optimizations: necko-chrome and necko-readonly are quickly found and 
always used.  Mozilla loads almost normally and the offline indicator shows the 
status of writable cache.

Comment 1

[Brendan Eich [:brendan]]

Timeless, please state the problem you're trying to solve here.  Don't jump to
an implementation conclusion that has unknown, possibly untoward inter-process
communication latency and other performance problems.

If the problem is "two Mozilla instances cannot share a cache directory
hierarchy and common cache files" then other, cheaper solutions come to mind.
Maybe we could have a multi-process-safe cache index.  Perhaps we need some
amount of immutability or journaling to share efficiently.  But I would not move
necko code out of process just to share cache files, without a lot more thought
and experimentation.

Cc'ing netlib owners/peers/grandfathers.

/be

Comment 2

[timeless]

Oh right, details. This is a logical expansion of the nightmare that is bug 
40109 [RFE] Ability to start two instances of mozilla.

Yes it does imply IPC nightmares.  And there would need to be a pref-holder 
thing too, unless necko can manage preferences, bookmarks and history.

I'm actually not in favor of creating this nightmare. But i am sketching out 
how i think it would be implemented.

I talked w/ a friend who uses BSD and he reminded me that KDE, and Gnome have 
to do this same nonsense too.  They spawn off shared worker processes and have 
to be resillient to them dying (spawn new ones).

Personally I can run about 20 mozilla's on my w2k box, but it takes a lot of 
wizardry (half would be netscape6, and 9 pairs would be running in terminal 
sessions at no higher than 256 colors). I would most certainly regret running 
all 20 instances, and I have other ways to torture my box so I haven't run more 
than 5.

I'm not exactly sure if these resolutions deserve wontfix or future. Because 
someone external will probably have to address them.

Optimizations that follow the general concepts outlined in the other bugs I 
just filed could be done w/o the actual splitting of necko.

eg. if necko can run readonly then we could enable that button in the dialog. 
and if necko can easily/safely detect an in use cache directory to force the 
user to pick another/readonly then we could enable that functionality.  The 
actual split might be more conceptual, although to really safely share a signle 
cache directory as writeable I think would probably require an external 
arbiter.

<offtopic>
fwiw, the reason ie can do multiple instances is because it can use the os as 
that arbiter, ie doesn't manage the cache directories, it asks the os to get 
the files for it.

IE itself becomes and application that renders html, css and xsl files.  
Whereas netscape is a system that retrieves, caches and renders them.

People complain about the integration that microsoft managed, but they also 
missed the clever mechanism that microsoft used.

I can use notepad on w2k to open a url.  Or mspaint to open a graphic form a 
url.  Most apps get this feature w/o understanding what's happening, it's all 
transparent. And no IE isn't doing this, the OS is.  IE isn't integrated into 
the OS [as a future project I could remove IE], networking functionality is 
built into the OS, and it's accessible from the common dialogs.
</offtopic>

Comment 3

[Brendan Eich [:brendan]]

Please, let's resummarize this bug and talk about how to share a cache among
multiple processes, if that's the problem reported here.  Don't do architecture
for architecture's sake; don't jump to an implementation conclusion in the bug's
summary.  AFAIK, no one is demanding that Necko run as a "server" or "daemon"
process on one's client machine.

Regarding the offtopic: sharing inet.dll or whatever among windows apps does not
mean that the code in that DLL runs in a separate process.  It does mean that
any files accessed by that code must be read and written with appropriate mutual
exclusion.

/be

Comment 4

[benc]

mass move, v2.
qa to me.

Comment 5

[Braden]

I agree with Brendan re. this bug jumping to architectural conclusions. It
should be reformulated in terms of the problem that needs to be addressed. I
filed bug 134959 the other day, and I don't know whether it duplicates this one
or not.

If there is no clear way to reframe this bug, I recommend INVALID.

Comment 6

[Darin Fisher]

timeless: this bug is old... if you can address brendan and braden's comments
then feel free to reopen this bug.

marking INVALID.

Comment 7

[benc]

VERIFIED/invalid:

If you want a cache that is shared among two browsers, get a caching proxy server...