Hi Douglas, Douglas St.Clair wrote:
> <RANT ON> > > Hmmmm. First I'm generally pleased with OO. Good feature set. Nothing > I have cared about was ever broken. However a monolithic architecture > seems like a poor choice for an open source project. I don't know > anything about the organization of the OO team but I would assume that > people join because they are interested in some facet of the project. > They contribute to and test the element(s) that are associated with > that facet. As features are added testing becomes more complex who is > prepared to test the whole thing. Just because you have only one main executable does not mean that the architecture is monolithic. I assume that you know the concept of shared libraries and you should know that OOo uses it a lot. Offering functionality in one process instead of in several processes does not make a monolithic architecture. On the contrary: 5 single executables for Calc, Writer, Draw/Impress, Math and Chart but without any additional shared libraries would be much more "monolithic" than - as now - one executable and a lot of shared libaries. Another aspect: the part of OOo that is in soffice.bin would be the same in all hypothetic "swriter.bin" etc. So why not share it at runtime? It saves resources to do so and allows to integrate the applications much better (easier handling of common settings etc.). A little experiment: you can remove *all* application libraries (writer, calc etc.) and OOo will still start. Nothing won't happen of course if you click on the "new document" links in the start menu. Is that monolithic? I don't think so. You can read a little bit more about modularity here: http://blogs.sun.com/GullFOSS/entry/what_can_openoffice_org_learn One reason for the decision to have a common process for all OOo applications was that the Linux platform did not have an equivalent to the Windows OLE2 editing ("Inplace editing") and we had the requirement to implement it. With separated processes (yes! we had them at that time) this would require an inter-process communication technology with a suitable language binding. At that time (mid 1990s) we didn't have UNO that basically is able to provide that. But it cost us only a few weeks to change our code from having separated executables to only one small executable and so get rid of the requirement to have inter-process communication. In OOo 2.0 we finally re-implemented the Inplace Editing based on UNO. This gave us the inter-process technology and so basically now we could go back to separated executables. But - believe it or not - I see more disadvantages than advantages to do so, the most prominent ones are resource usage and quality of integration. I only see one advantage: a crash would bring down only documents of one type, not all documents. But how often does that happen? OTOH, the disadvanteges are felt everytime, the most prominent ones are: - more memory consumption - starting more than one app takes more time in total - less integration, less common settings etc. So in short words: the observation that OOo uses only one executable does not allow to conclude that it is "monolithic". OTOH indeed the modularity of OOo could be better, but this can be seen only if you study the source code. If you are interested, I recommend my presentation from last year's OOoCon: http://ooocon.kiberpipa.org/media/index-2007.html (search for "Mathias Bauer" and you will find links to a video and the slides). > There are two potential areas of risk. The unfortunate error that > brakes something subtle. Something that is not part of the test suite > something that doesn't get added to the test suite because of the > complexity of the entire package and so it goes un-noticed possibly > messing up someone's important spreadsheet. The other error is one > done by some SOB who deliberately codes backdoors that share people's > databases with him or just maliciously and destructively impacts > peoples work. > > The ability to test a whole bunch of little pieces, decompose the > system into only the pieces you want or need, does a lot to minimize > both the errors (because the builder had more control over their > piece) as well as the ability of users to simply delete pieces they > don't want or need thus avoiding either type of error coming from > pieces they don't want or need. All of this is true, but it is not related to the fact whether the applications are started in one process or in different processes. It's more a question of how good the code is organized in the shared libraries and how modular they are. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
