Yegor Jbanov wrote: (a definition of modularization)
Thanks for this nice roundup. I see a lot of common understanding, so basically we have a similar idea about what a perfect modularization can be. My point just is that for me modularization isn't a black and white thing, it has a lot of gray shadings. I think that in this regard OOo has a grey colour somewhere on the scale, the opinion about how dark the grey is IMHO is very subjective and depends on from where you look at it. If you look from the outside, it's pretty dark, if you look from the inside and know where the problems but also where the good things are, you can come to different conclusions. Anyway, I would like to see the grey turn brighter. We never will reach the white end - IMHO for such a big project this is close to impossible if it hadn't been there from the beginning. >> I agree that our documentation needs improvement (you could volunteer to >> help). But with some good will you can find a lot of interesting things >> in the Developer's Guide. It e.g. explains how the application framework >> of OOo works and you can indeed see this as a documentation of the >> modular structure of OOo. > > This is where modularization could help a lot. Having documentation > for each module will make sure that we don't have any big holes. I > agree that you can find a lot of interesting things in the guide. This > does not mean however that we have documentation we could build with. > It has to cover every piece of functionality that is designed to be > used by extension developers, core developers, and developers of > applications importing a sub-set of OOo modules as external libraries. > Things that are not yet documented could at least point into the > source code where a skilled programmer could understand the concepts > by reading the code. By the way I find links to specs completely > useless and confusing. Most of these specs seem so far away from > reality. They look more like internal Sun documents that used to be > drafts of the functionality that was going to be implemented but was > implemented completely differently. Well, you know that real programmers don't read manuals. They even more don't like to write some. ;-) It's hard to get people to write documentation when there still is such a lot of things to do with actual coding. And the documention written by developers about their own code often is not easy to understand by others. I regret all this but I don't have an idea how this could be changed easily. Getting contributions from other developers that have built up some knowledge could help in both cases: we get more documentation and perhaps better documentation because the writer has actually done what (s)he describes and already knows the traps and pitfalls. > Let's try a little experiment. This page > (http://wiki.services.openoffice.org/wiki/Extensions_best_practices) > claims that UNO AWT has a very high priority. Now, try searching for > "UNO AWT" in Google and see what you get. The problem here is that we have quite some documentation about aspects of the UNO AWT, but obviously it's hard to find. Thanks for pointing me to this, I will discuss that with the developer that provided it. > I develop extensions for OOo and did have some occasions where I had > to find things out by trial-and-error and I probably can help > documenting some things. This would be great. As I'm involved in the framework team where the toolkit is maintained nowadays, I will be glad to work together with you. Jürgen Schmidt, our API project lead also will help, I'm sure. As our DevGuide is part of the OOo Wiki, it's basically at least easier to cooperate as it was when the DevGuide was maintained only by Jürgen. >> There are parts of OOo that lack modularization, but even where the >> modularization is missing on package or library level there may be clear >> architecture on the code level. > > Again, this helps the core developers to maintain code. But until you > can build a module as a standalone shared library or link it into your > own code base, this kind of "modularization" only accomplishes 5% of > what it could otherwise. Right. It's clear that the re-usability of OOo code in other projects isn't in our focus. I hope it's understandable that our main interest is the success of OOo as an end user application. It may be even a bit short-sighted, I don't know. But that's as it is. >> The new chart component that we added in OOo2.3 is a good example for >> what is there and how it can be used. All three parts of this >> "application" (model, view and controller code) are in a separate >> library. And there are no dependencies of the Framework on any of these >> libraries, objects from these libraries are instantiated as UNO >> services. You can remove Chart from the installation without breaking >> anything - except sloppy written code that expects that "their always is >> a Chart". But this is not a problem of bad modularization or >> architecture, that's just a bug. > > With proper modules, you wouldn't even have a chance to accidentally > introduce such a bug. The code wouldn't compile due to broken > dependencies. No, there is no broken dependency here. Chart objects are instantiated as UNO services, there is no link dependency you could check. The bug I was talking about was that perhaps some code tries to instantiate such a service but doesn't check the success. This is a simple bug and not related to modularization. > I hear you, and I understand your concern about the impact on the > development of the core functionality. I am trying to add another > dimension to the discussion of the modularity. Namely, from the point > of view of an external developer, like myself. If only I had a chance > to use these libraries without having to build/install the whole > office suite, I could help a lot with the development as I am very > interested in improving the quality OOo in general, but I can only > help with a small portion of it. I only have maybe 10% of my time that > I can dedicate to this. Right now I need a month of full-time > immersion to understand what OOo is made of internally. Now think > about hundreds of other developers who wish to help but can't, then > multiply by 10%. You don't have to do the math to realize that that's > a whole bunch of extra enthusiastic man hours that could be poured > into OOo. Agreed. Nevertheless you should see the psychological problem: the effort to get there would prevent developers from actually implementing features and fixing bugs for quite some time. This is something that neither most developers nor the majority of our users would like. So there is a barrier to overcome. The best thing to work with this situation is trying out changes in small projects, but not to change the general direction of the project. But where to start? First we need to get an idea which parts of OOo might be interesting for others. Filters may be one part, but what else? Another problem is that many code in OOo uses the UNO component model. I already heard at several times that developers don't like to use it because it's "proprietary". I think that this argument is bogus (then why should anyone consider using e.g. Mono?) and it overlooks that UNO has already proven that it is fast, stable and powerful and it only stays "proprietary" *because* other refuse to use it even if it alreasy is available as a separate "module" (URE). > Well, this is the law, isn't it? How do you expect me to use an > external library and not adapt to its core model and API? :) Sorry, I obviously have pigeonholed you in the drawer of people that claim that OOo and AbiWord of KOffice should share their filters and here exactly the problem is as I described it. > Instead, I am eager to use your APIs and models, just give me a chance. And if > I find a bug I'll report it, or better, fix it and send you a patch. > What I really want, is that I take a file in any format and convert it > (or import it) into a single format I can rely on and then apply my > own business logic to it. If it is some core OOo object model, I am ok > with that. What I want after that is take this model and save it > (export) to some format of choice. Or if I am generating reports and I > want to support multiple formats, I would create that model in memory > from some data and then export it using OOo filters module. All I want > that module to do is bundle a set of filters for formats that I want > to support, provide type detection capabilities and provide access to > the DOM. I do not need any UI around it. Our new ODFDOM project partly addresses that, but it's a "pure Java" toolkit and so can't be used by our filters ATM. If we had used a UNO based implementation of ODFDOM, we already had something where developers could start to combine it with our new filters. But the developers of the ODFDOM project feared that a UNO based solution wouldn't get the same acceptance as a Java based one. I'm afraid that they are right. >> Admittedly currently this will pull in even some unnecessary code, as >> e.g. the UI code of Writer that surely isn't needed in a converter. And >> this is one reason why I would like to separate all UI code from the >> core model code so that we could create a converter that does not > > I applaud to that! Thank you very much! I believe this will bring a > lot of good. This is another step towards modularization. Glad you like it, but I assume that this will be quite some work to do. >> IMHO all code that is needed to work with the application's feature set >> is mandatory code and it must be part of even the smallest possible >> converter or any other application you want to build on OOo's >> capabilities (that are themselves based on ODF). > > You are being too restrictive here. Proper separation of concerns will > easily reveal orthogonal features and allow standalone usage. Yes, again I took the core developer's POV. For me the separation of model and controller has higher priority than the split of the model into smaller peaces. > I am not suggesting that any ODF functionality (or internal DOM > functionality) should be split into modules, but at least it should > not include any UI dependencies and should itself be a module. Here is > an example of how modules could be organized: > > "Type Detection Module" uses one-or-more "Filter Modules" uses "ODF > (DOM) Toolkit" This would be wonderful. But if we went that way despite the problem with ODFDOM I mentioned above, we would get another big problem: we had to exchange the current Writer core and implement new layout and view code based on the new model (as the old code is C++ code, not even using UNO). Even if we ignored the huge effort to rewrite large parts of the other code from scratch, we couldn't ignore what this would mean for our users. From more than 10 years of experience we know that especially Writer users are very picky about the layout stability of their documents. So if they got a new Version of OOo where even small differences in the layout are found, they would complain a lot. OTOH it's close to impossible to write new layout code from scratch that works *exactly* as the old code in *all* situations. Can you see our dilemma? If you were asking me what my personal preference would be if I didn't need to care for resources: - a new core based on ODFDOM (ported to C++ or equipped with a UNO wrapper around the Java code), a well designed, modular layout code with perhaps only 95% layout compatibilty and a completely separated, exchangeable UI or - keeping the current, tuned and non-modular code I wouldn't need a long time to chose. But in the real word I *have* to take care for resources and even more: I have to take care for what users want from us. So if someone has a tool to destroy the Gordian knot: I would like to buy one. :-) 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]
