Thread
:
Browser Switchboard - use any browser as the default
View Single Post
steven676
2010-02-18 , 08:13
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#
88
Originally Posted by
daperl
If you feel like it, I wouldn't mind a short synopsis why you think so.
There are a few general (and one specific) concerns I have about merging non-browser-related default program selection functionality into browser-switchboard:
Complexity -- we go from building a program to handle one D-Bus interface with one clearly defined purpose and essentially a single method (launch a browser) to handling multiple D-Bus interfaces that do quite different things. Not impossible, perhaps not even hard depending on what the other functions involve, but not as straightforward as now.
Packaging complexity -- we have to replace more files that shipped with the system, and if we screw up in one place (as I did several times when developing the packaging for Browser Switchboard!), we can now potentially break more than one function.
Code size -- with continuous mode off (the default), performance should be (I haven't measured) almost completely determined by startup time, which in many cases is going to be completely determined by how long it takes to load the code from stable storage.
One problem specific to launching MicroB: currently, we don't go back into the event loop to process more D-Bus messages until after MicroB finishes, which could take a very long time. This is fine if we only handle the osso_browser interfaces (we let MicroB handle those while it's open), but we'd have to remove this restriction if we don't want handling of mail/media requests to stop while MicroB is open, and doing so would make already complex code even worse.
On the other hand, I see only one minor advantage to handling all of these functions in one program:
Memory footprint -- one small program dispatching two or three different services will save a few hundred KB over two or three small programs each dispatching one service.
With that in mind, I think it'd be best to have different backend programs for each interface we want to handle, each of which ships in a different package. The programs could share a configuration UI and possibly also code (where that makes sense). I don't know whether those different programs belong in the same codebase or in separate projects.
As usual, anyone is welcome to prove me right or wrong with patches
Quote & Reply
|
The Following 2 Users Say Thank You to steven676 For This Useful Post:
daperl
,
qwerty12
steven676
View Public Profile
Send a private message to steven676
Find all posts by steven676