Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Yegor, sorry for the late reply, I was too busy for a well-thought answer. Yegor Jbanov wrote: I am going to try to be constructive. First, let's see if we can simplify the problem statement. I will try to do that by asking two questions: 1. If OpenOffice.org had a sibling project called OpenOffice.org Server, what features would it have to provide to be useful? I think the goal should be that no UI components should be necessary to run it. Without going too much into details, just separating core and UI wouldn't be enough, we also must solve the problem that some wanted features (e.g. format conversion) will need an output device as they require layouting. Both is solvable with evolutionary code changes, but admittedly a lot of them. No reason to restart from scratch. 2. How big an effort would it take to accomplish such a project? That's hard to estimate, even finding a proper estimation could last days and weeks. My guesstimate is 3-12 months, depending on the number of developers working on it. But I may be wrong here because my knowledge about Calc and Impress is limited. I can answer the first question from my point of view. I am sure others will find other features that they would want to have. First of all, I would like to be able to deploy the Server on a machine that has no windowing system. Second, it would be nice to have multi-language support (Java, C++, Python, etc), possibly through UNO. ODF Toolkit, filters and type detection should be there of course. I suppose dictionaries and spell checker also belong there. No doubt there is more. That's possible already, but only with the notorious headless hack, as you wrote yourself. So the features alone don't require any changes, but of course the architecture. The second question is the hardest and I guess it's the core developers who can give a more accurate answer. I would like to note that the need for a server component has been recognized a long time ago and it was partially addressed. However, the chosen approach was a hack and it is still a hack. Connecting to a headless GUI application through sockets/pipes is not a solution. You are right, it never was meant to be anything else than a stopgap solution. But as we all know, stopgap solutions often tend to be very durable... It is an approach you keep secretly for those times when it is desperately necessary, but you don't mention it a lot in order not to embarrass yourself. Too much of that GUI nature is leaking through the API. It is not stable. It is full of memory-leaks. While I agree that the headless hack is ugly, it is not necessarily the root cause for instability and memory leaks in the current release. I think the superfluous UI code executed in server mode even adds less to that than the needed core code. You are right from a theoretical POV: superfluous code never can be good. So back to the facts. As I wrote somewhere else, in Writer we have thought about and worked on refactoring for quite some time. I already have an idea how to get rid of most of the high level UI code. There are still some challenging plaitings to solve, but I like challenges. :-) If you are asking me if there will happen something in the near future: I can't answer that. The interesting point is how to find the right balance between the different interests: - we always must keep pace with the ODF proceedings and still have to iron out some bugs in our current ODF support (this is vital for OOo and out of any discussion) - some users want us to implement features they are asking for, to some extent since quite some time - some users want us to fix the bugs that annoy them, also partly since quite some time - some users ask for performance improvements - others (mainly developers of course) ask for better modularization. My personal POV is that it's time to consider the two latter points stronger than in the last two major releases. But that's only me. I hope that the next weeks and months will show us where we will be heading to in the 3.x releases. Regards, 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, On Tue, 2008-09-30 at 18:03 +0200, Mathias Bauer wrote: My personal experience with asking people about possible code sharing quite often was: I don't like UNO, I don't like Windows, I don't like your build system etc. etc. While some of these statements are valid, I always wonder why nobody says: nice idea, how to make it happen and how can I help you. Well, it's clear we need to go out and evangelise. This is the difference between passive and pro-active :-) There are also more telling issues such as control, ownership, timeline RCS of shared code that tend to be problematic - but that aside ... one of the first things I tried to work on (back in 2001) was using autotools for sal / cppu etc. such that we could re-use UNO elsewhere in the Gnome desktop: that met with resounding loathing from the build.pl / dmake lovers - and was one of the things that killed that co-operation (AFAIR). [ and I was doing the work and trying to contribute it (even in parallel with dmake foo) ]. Strangely, not the first time that our passion for our (frankly unbelievable) build-system has substantially hindered useful co-operation with others ;-) Ultimately, if we want to evangelise our technology it is necessary to meet the other people where they are, listen to their problems and adapt to them. Technologies that don't do that fail in the long term. Of course, there is a lot for others to dislike in UNO - the UCS-2/UTF-16 Win32 heritage of all strings, the appalling intrinsic threading / granularity problems ( un-addressed by apartments ), and so on: but at least it should be a no-brainer to share non-UNO-using pieces of the infrastructure. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Yegor Jbanov wrote: 2008/9/30 Mathias Bauer [EMAIL PROTECTED]: Thorsten Behrens wrote: Hm. That's a funny thing with the users. They tell you they want 100% layout compatibility, and then they move on to Mac use Pages, because it's 'good enough' and so much nicer. There are smart people out there, opining that when disruptive changes happen (and they do, with web-based offerings, mobile phones etc.), you better not listen to your established user base - I recommend (re-)reading Clayton Christensen. ;) We don't have the users. My fear is that a not so small and not so unimportant part of our users (the corporate users and those from the public sector) fall into the categorie of whatever you do, don't spoil my document layout!. We see that everytime we accidently (or intentionally ;-)) broke something for them, e.g. if we fixed a bug of an old OOo version and now documents look different. Maybe that this is a very Writer-specific problem, but at the end this is the application I was talking about. I fail to see how modularization could break the layout of imported documents. Why anything has to be rewritten from scratch? I wasn't talking about modularization in general, I was talking about a new Writer core that *I* would like to have (hey, I'm allowed to have dreams and wishes also! :-)). Is it because of bad code design? If classes/functions from one namespace do not refer to another namespace directly or indirectly, why should it be so hard to package that namespace as a standalone module? If there is a dependency, say on some UI class, which was probably created accidentally, then why removing it should imply a rewrite of the whole thing? Of course. As I already wrote, separating UI and core in Writer is nothing I would see as impossible. That would improve the architecture, but it wouldn't give usable modules as the internal core interfaces are not stable. Thus my sidestep to the ODFDOM core. Seems that got mixed up in your thoughts a bit. I hope I made it clear now. I have to agree with Thornsten that protecting existing user base at the expense of potential new users and new paradigms is not a good roadmap for OOo. I would say it's a sure way towards a failure. I think you are jumping to conclusions. I never wrote that we shouldn't look for different concepts, I only stated that I see a huge problem with an important part of our user base for that I don't have a solution ATM. But that doesn't exclude modularization in general, just this particular part of it. To avoid further misinterpretation: Do I support better modularization? --- Yes, wholeheartedly, not only by talking about it but also by actively working on it, not only in future but also since several years. Do I like the idea to share code with other projects? Yes. And better modularization is a precondition for that. But sharing code with others is not the only reason for modularization, so we shouldn't mix these two things. Do I want to support that actively? -- Yes. First by working on better modularization and second by supporting people that try to remove obstacles. Do I want to do that at any price? --- No. I still consider working on the OOo code to make it better as more important than trying to(!) share code with others. And I can't believe that anybody else interested in the project could think differently. OOo is not a stone pit, it's a building. It may not have the best possible architecture, but as long as it has such a huge success as now we shouldn't erode it completely before we have at least the blueprint for its successor. What can be done in reasonable limits should be done. But nothing that entails a huge risk to damage the project considerably. What is reasonable and what not surely is open and may even change in the future. And we shouldn't forget that talk is cheap. If someone wants to get something changed: help doing the change. Regards, 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
I am going to try to be constructive. First, let's see if we can simplify the problem statement. I will try to do that by asking two questions: 1. If OpenOffice.org had a sibling project called OpenOffice.org Server, what features would it have to provide to be useful? 2. How big an effort would it take to accomplish such a project? I can answer the first question from my point of view. I am sure others will find other features that they would want to have. First of all, I would like to be able to deploy the Server on a machine that has no windowing system. Second, it would be nice to have multi-language support (Java, C++, Python, etc), possibly through UNO. ODF Toolkit, filters and type detection should be there of course. I suppose dictionaries and spell checker also belong there. No doubt there is more. The second question is the hardest and I guess it's the core developers who can give a more accurate answer. I would like to note that the need for a server component has been recognized a long time ago and it was partially addressed. However, the chosen approach was a hack and it is still a hack. Connecting to a headless GUI application through sockets/pipes is not a solution. It is an approach you keep secretly for those times when it is desperately necessary, but you don't mention it a lot in order not to embarrass yourself. Too much of that GUI nature is leaking through the API. It is not stable. It is full of memory-leaks. Any thoughts? Yegor 2008/10/1 Mathias Bauer [EMAIL PROTECTED]: Yegor Jbanov wrote: 2008/9/30 Mathias Bauer [EMAIL PROTECTED]: Thorsten Behrens wrote: Hm. That's a funny thing with the users. They tell you they want 100% layout compatibility, and then they move on to Mac use Pages, because it's 'good enough' and so much nicer. There are smart people out there, opining that when disruptive changes happen (and they do, with web-based offerings, mobile phones etc.), you better not listen to your established user base - I recommend (re-)reading Clayton Christensen. ;) We don't have the users. My fear is that a not so small and not so unimportant part of our users (the corporate users and those from the public sector) fall into the categorie of whatever you do, don't spoil my document layout!. We see that everytime we accidently (or intentionally ;-)) broke something for them, e.g. if we fixed a bug of an old OOo version and now documents look different. Maybe that this is a very Writer-specific problem, but at the end this is the application I was talking about. I fail to see how modularization could break the layout of imported documents. Why anything has to be rewritten from scratch? I wasn't talking about modularization in general, I was talking about a new Writer core that *I* would like to have (hey, I'm allowed to have dreams and wishes also! :-)). Is it because of bad code design? If classes/functions from one namespace do not refer to another namespace directly or indirectly, why should it be so hard to package that namespace as a standalone module? If there is a dependency, say on some UI class, which was probably created accidentally, then why removing it should imply a rewrite of the whole thing? Of course. As I already wrote, separating UI and core in Writer is nothing I would see as impossible. That would improve the architecture, but it wouldn't give usable modules as the internal core interfaces are not stable. Thus my sidestep to the ODFDOM core. Seems that got mixed up in your thoughts a bit. I hope I made it clear now. I have to agree with Thornsten that protecting existing user base at the expense of potential new users and new paradigms is not a good roadmap for OOo. I would say it's a sure way towards a failure. I think you are jumping to conclusions. I never wrote that we shouldn't look for different concepts, I only stated that I see a huge problem with an important part of our user base for that I don't have a solution ATM. But that doesn't exclude modularization in general, just this particular part of it. To avoid further misinterpretation: Do I support better modularization? --- Yes, wholeheartedly, not only by talking about it but also by actively working on it, not only in future but also since several years. Do I like the idea to share code with other projects? Yes. And better modularization is a precondition for that. But sharing code with others is not the only reason for modularization, so we shouldn't mix these two things. Do I want to support that actively? -- Yes. First by working on better modularization and second by supporting people that try to remove obstacles. Do I want to do that at any price? --- No. I still consider working on the OOo code to make it better as more important than trying to(!) share code with others. And I can't believe that
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
On Wed, Oct 01, 2008 at 01:00:43PM -0500, drhooo wrote: Does this refer to work that has been completed and is in the CVS or Subversion system, or is it a work in progress in a CWS? Where should one look to learn more about this (and maybe use it)? This is in ooo-build, a build system set of patches around OOo. More on http://go-oo.org/ HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Moin Thorsten, Thorsten Behrens wrote: Hi Mathias, you wrote: 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. You correctly described the status quo, thanks for that and also for the very nice write-up of the general problem. I'm nevertheless wholeheartedly convinced that this focus is utterly wrong, and was therefore tempted to post a little rant on my blog (http://blog.thebehrens.net/2008/09/29/ooo-non-vision/). I think that your blog is a little bit unfair and so I posted a comment. But now let's become constructive. 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 haven't touched Writer code with a ten-feet pole (well, okay, maybe I've fixed a handfull of graphics bugs), but - ain't there an in-between, a possibility to refactor? That's what Armin did with the drawing layer, and I would consider that successful. Of course. And refactoring in Writer is always on our list. I gave an outlook on some possible improvements in my talk in Barcelona and I will present more in the near future. We already refactored our core-layout interface. Unfortunately we are now stuck exactly in the drawing layer Or more precicely: our problems are grouped objects and form controls that don't support the idea of a 1:n relation between core and layout properly. But we haven't given up. Would be nice to get some support of people in the know (perhaps you?). But we already have done a huge amount of refactoring in the last years (most of them also have been mentioned in my talk in Barcelona) in the framework. Refactoring the framework was the inevitable first step before we can modularize the code of the applications, as in former times the framework functionality has been smeared over a lot of libraries and classes that e.g. Writer directly linked to. Nowadays the framework nearly completely is made up of exchangeable and extendable UNO services. 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. :-) Hm. That's a funny thing with the users. They tell you they want 100% layout compatibility, and then they move on to Mac use Pages, because it's 'good enough' and so much nicer. There are smart people out there, opining that when disruptive changes happen (and they do, with web-based offerings, mobile phones etc.), you better not listen to your established user base - I recommend (re-)reading Clayton Christensen. ;) I would be glad to see my apprehension unjustified. I don't want my statement be understood as a I never would do that because the users won't like it, more like a before I will do that I must have the impression that it can be accepted by the users. So while this statement isn't a description of the status quo only, it also isn't a vision. It's just loud thinking about how I could implement my vision. As promised elsewhere in this thread I will present them (or the more general part of it) soon. Regards, 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, you wrote: I think that your blog is a little bit unfair and so I posted a comment. Sorry if it came across like that - I did not mention your name there, as this was not meant as a personal attack, but I was rather challenging this (IMO) wide-spread mind-set the quote so nicely captured. Or more precicely: our problems are grouped objects and form controls that don't support the idea of a 1:n relation between core and layout properly. But we haven't given up. Would be nice to get some support of people in the know (perhaps you?). Although my personal focus would be more on the gsl side of things, I wouldn't rule out the possibility ;) Any more details (maybe off-list)? I would be glad to see my apprehension unjustified. I don't want my statement be understood as a I never would do that because the users won't like it, more like a before I will do that I must have the impression that it can be accepted by the users. Nah. The dilemma I was referring to is that the users will _not_ accept it this year, but two or three years down the road, they'll flock over to those other offerings nevertheless, _despite_ the fact that those are worse than OOo on that metric - because their value network has changed, i.e. all of a sudden the relative importance of e.g. collaboration or ease of use backward compatibility has changed. So while this statement isn't a description of the status quo only, it also isn't a vision. It's just loud thinking about how I could implement my vision. As promised elsewhere in this thread I will present them (or the more general part of it) soon. Looking forward, really. :) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Thorsten Behrens wrote: Hm. That's a funny thing with the users. They tell you they want 100% layout compatibility, and then they move on to Mac use Pages, because it's 'good enough' and so much nicer. There are smart people out there, opining that when disruptive changes happen (and they do, with web-based offerings, mobile phones etc.), you better not listen to your established user base - I recommend (re-)reading Clayton Christensen. ;) We don't have the users. My fear is that a not so small and not so unimportant part of our users (the corporate users and those from the public sector) fall into the categorie of whatever you do, don't spoil my document layout!. We see that everytime we accidently (or intentionally ;-)) broke something for them, e.g. if we fixed a bug of an old OOo version and now documents look different. Maybe that this is a very Writer-specific problem, but at the end this is the application I was talking about. So my ideas of what we can improve in the forseeable future don't are about how can we split up or exchange the core. But there's enough to do elsewhere that can move us forward. And nothing that we can do will make the hurdle for a core model exchange higher than it is alraedy. 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
2008/9/30 Mathias Bauer [EMAIL PROTECTED]: Thorsten Behrens wrote: Hm. That's a funny thing with the users. They tell you they want 100% layout compatibility, and then they move on to Mac use Pages, because it's 'good enough' and so much nicer. There are smart people out there, opining that when disruptive changes happen (and they do, with web-based offerings, mobile phones etc.), you better not listen to your established user base - I recommend (re-)reading Clayton Christensen. ;) We don't have the users. My fear is that a not so small and not so unimportant part of our users (the corporate users and those from the public sector) fall into the categorie of whatever you do, don't spoil my document layout!. We see that everytime we accidently (or intentionally ;-)) broke something for them, e.g. if we fixed a bug of an old OOo version and now documents look different. Maybe that this is a very Writer-specific problem, but at the end this is the application I was talking about. I fail to see how modularization could break the layout of imported documents. Why anything has to be rewritten from scratch? Is it because of bad code design? If classes/functions from one namespace do not refer to another namespace directly or indirectly, why should it be so hard to package that namespace as a standalone module? If there is a dependency, say on some UI class, which was probably created accidentally, then why removing it should imply a rewrite of the whole thing? I have to agree with Thornsten that protecting existing user base at the expense of potential new users and new paradigms is not a good roadmap for OOo. I would say it's a sure way towards a failure. As for lack of resources, modularization is necessary precisely because current OOo team cannot possibly handle all use-cases for OOo components. So let's allow others use those components outside of OOo and not bother the core team. So my ideas of what we can improve in the forseeable future don't are about how can we split up or exchange the core. But there's enough to do elsewhere that can move us forward. And nothing that we can do will make the hurdle for a core model exchange higher than it is alraedy. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Thorsten Behrens wrote: Hi Mathias, you wrote: I think that your blog is a little bit unfair and so I posted a comment. Sorry if it came across like that - I did not mention your name there, as this was not meant as a personal attack, but I was rather challenging this (IMO) wide-spread mind-set the quote so nicely captured. Well, IMHO we have started to think about questions like these already some time ago, but we didn't develop this into something that you call vision but I would prefer to call a guideline. I had some talks about that in Barcelona and - what are the odds! - it was a topic of a talk I had with Kay Ramme yesterday. There are some elements that make it hard to think into this direction. My personal experience with asking people about possible code sharing quite often was: I don't like UNO, I don't like Windows, I don't like your build system etc. etc. While some of these statements are valid, I always wonder why nobody says: nice idea, how to make it happen and how can I help you. The fixed mind-set isn't on one side only. Developers neglecting the importance of other platforms than Linux never will be able to understand what we are doing (please note that I wrote understand, not like). Or more precicely: our problems are grouped objects and form controls that don't support the idea of a 1:n relation between core and layout properly. But we haven't given up. Would be nice to get some support of people in the know (perhaps you?). Although my personal focus would be more on the gsl side of things, I wouldn't rule out the possibility ;) Any more details (maybe off-list)? I think as this is a very code-centric debate, we should do it elsewhere. I would be glad to see my apprehension unjustified. I don't want my statement be understood as a I never would do that because the users won't like it, more like a before I will do that I must have the impression that it can be accepted by the users. Nah. The dilemma I was referring to is that the users will _not_ accept it this year, but two or three years down the road, they'll flock over to those other offerings nevertheless, _despite_ the fact that those are worse than OOo on that metric - because their value network has changed, i.e. all of a sudden the relative importance of e.g. collaboration or ease of use backward compatibility has changed. See my other reply: it was my fault to talk about the users, we should see it as a problem of a particular part of our user base (that we IMHO can't neglect). We have to find out how to convince them that improving the OOo architecture and prepare it for future challenges is worth some layout quirks. 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, you wrote: My personal experience with asking people about possible code sharing quite often was: I don't like UNO, I don't like Windows, I don't like your build system etc. etc. While some of these statements are valid, I always wonder why nobody says: nice idea, how to make it happen and how can I help you. The fixed mind-set isn't on one side only. Definitely. But then, excuse the business metaphor, in a market setting, one usually doesn't blame the buyer for not buying, but the seller for failing to sell - and after all, the seller and the offering is all we (possibly) have influence on. ;) And, as you conceded, convincing other projects to swallow larger subsets of OOo wholesale (as up to now, there are no real independent parts - the smallest piece that makes sense would be build system, boost, stlport, xml2cmp sal, the next one probably already URE - all of which would force the other project into _our_ world, build-system, packaging configuration-wise), when they want to share some bits, is hard to say the least. That said, at least on Linux, Michael did split OOo up into 18 distinct packages, that build on top of each other, and can be independently built installed (and most importantly, one can install debug info only for e.g. Writer) - but that's still OOo, much better packaged, but dragging in the whole stack, if someone links against svx for the Escher filter. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
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
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
[ I can't resist to take the bait ] Hi, Bernd Eilers wrote: It´s all already 'modularized' and there do exists already ongoing Not in the source. You even can't build the extensions without an OOo build env yet. You can't build them against the SDK. You can't build the URE separately and not build OOo against that URE. What you think is not always what the facts are. efforts to split up the installation files into packages which depend of each other - been there done that! - so what? This is not something that Just that those packages you currently have suck great balls. And that when you want to make it sane you get crashes because e.g. calc cannot find libdba. (when you move libdba to -base and -base is not installed). So far for a working component model. is such a great new idea that we would not already working on since a long time. With no visible effects. And if stuff is visible it's broken (see the package split example above and the usles coreXY). Do a real core and do sane packages- Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Amen to that! Plus: 1. Documentation is the suckiest thing about OpenOffice.org SDKs and APIs. If OOo has been modularized, then nobody ever noticed. Is there a module dependency diagram anywhere? (This was a rhetorical question, of course.) We need a central, comprehensive, well-organized and up-to-date documentation web-site (take a look at how Google documents their toolkits). The official documentation is so badly organized/out-of-date/incorrect/incomplete that even Google fails to find relevant information. My major source has been so far the mail archive where people report their questions and sometimes get their answers, yet nobody ever cares to update the documentation so that others could find it easily. 2. OOo file filters must become a standalone project that could be shared with KOffice, AbiWord and others. In general, having ability to use filters outside OOo is a major advantage. There are so many use-cases for filters other than opening Word files for editing in OOo. Content management systems (Alfresco), reporting software (JFreeReports), document intelligence (redaction), web-office suites (Zoho, GDocs), etc, all need multi-format support. Needless to say that this will tremendously increase the quality of the filters as you gain access to a much bigger developer community. Open-source is about avoiding reinventing the wheel and about enhancing the existing wheel. Cheers, Yegor 2008/9/26 Rene Engelhard [EMAIL PROTECTED]: [ I can't resist to take the bait ] Hi, Bernd Eilers wrote: It´s all already 'modularized' and there do exists already ongoing Not in the source. You even can't build the extensions without an OOo build env yet. You can't build them against the SDK. You can't build the URE separately and not build OOo against that URE. What you think is not always what the facts are. efforts to split up the installation files into packages which depend of each other - been there done that! - so what? This is not something that Just that those packages you currently have suck great balls. And that when you want to make it sane you get crashes because e.g. calc cannot find libdba. (when you move libdba to -base and -base is not installed). So far for a working component model. is such a great new idea that we would not already working on since a long time. With no visible effects. And if stuff is visible it's broken (see the package split example above and the usles coreXY). Do a real core and do sane packages- Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Rene Engelhard wrote: [ I can't resist to take the bait ] Well, perhaps you better had. It's amazing that people easily talk at cross-purposes just because everybody is riding is own hobby-horse. Bernd critized the incorrect assumption that OOo's UI problem would be caused by a monolithic architecture. And this is undoubtfully correct. IMHO it's also undoubtfully correct that the architecture isn't totally monolithic. Admittedly it also isn't as modular as one would want to have it (and that indeed adds to the UI problems) - but hey, that's surely an intermediate state as we - as Bernd pointed out correctly - always try to become better over the years. Motivated by another thread on this list ;-) I will present some *concrete* ideas how to improve that (and some reports about what we have achieved so far) soon. Of course we still will need time and resources to actually *do* something (talk is cheap). You correctly pointed out that any possible architectural improvements of the past didn't show up in the packaging. From that you may conclude that we didn't care much for the packaging in the past (what indeed is true except for the last few months), but it doesn't make Bernd's statements wrong as he talked about the architecture, not the packaging. The packaging also depends on the build system and especially on the notorious scp2 and instsetoo_native modules, it's not the code and the object architecture alone that can be made responsible for a bad packaging. Bernd and you just have talked about completely different things, though both are somewhat related. To get back to positive things: I fully support your wish for a better modularisation of the code, the build process and the packaging. I'm thankful for good concrete suggestions how to achieve that and of course I would be even more thankful for some helping hands. 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]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Yegor Jbanov wrote: Amen to that! Plus: 1. Documentation is the suckiest thing about OpenOffice.org SDKs and APIs. If OOo has been modularized, then nobody ever noticed. May be because it's always easier to maintain prejudices than to actually check them against reality from time to time. I don't say that OOo is perfectly modularized, but it's also far away from being a monolith. As I explained in my reply to Rene IMHO people tend to think that just because one particular aspect of modularity is not visible that their can't be any kind of it. And that's not true. Is there a module dependency diagram anywhere? (This was a rhetorical question, of course.) We need a central, comprehensive, well-organized and up-to-date documentation web-site (take a look at how Google documents their toolkits). The official documentation is so badly organized/out-of-date/incorrect/incomplete that even Google fails to find relevant information. My major source has been so far the mail archive where people report their questions and sometimes get their answers, yet nobody ever cares to update the documentation so that others could find it easily. 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. 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. 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. The same separation of application and framework BTW is true for Writer, Calc etc. also, thanks to the very modular and abstract design of the framework. But admittedly the *internal* structure of these modules lacks modularization. Currently only the dialogs of e.g. Writer are in a separate libary. My idea is to extend that to the whole UI code somewhere in the future. But this is quite some work to do and we can't take ourselves out of the ongoing development for a year or so, so we have to work on modularization along the way. The biggest problem in this area still are our Drawing Layer, the EditEngine/Outliner and the forms layer that together totally undermine any attempt to implement a model/view/controller separation in Writer (I can't speak for Calc and Draw/Impress here). But I know that a very motivated developer is trying to fix that even if it costs him several years of his life time. ;-) 2. OOo file filters must become a standalone project that could be shared with KOffice, AbiWord and others. In general, having ability to use filters outside OOo is a major advantage. Are you sure that you know how filters work? They don't convert from format A to format B, they convert from a format to an API or core model. As long the applications don't share the core model and the API they never will be able to share the filter code. Of course you can share parts of the filters, e.g. as in case of the libwpd that converts the imported format to a somewhat idealized model. But you always will need some code around it that adapts this to the concrete model of the application you want to import to. Here's an example: our new docx import filter consists of three components. One is the parser/tokenizer component that scans the file and generates kind of events that make up an idealized and very low-level model. Another component, the so called domain mapper converts this into API calls using the API of the document core model. The API builds up a still idealized but already very concrete model. The implementation of this API can be seen as the third part and it can adapt from the still idealized API view to the very bits and bytes of the C++ source code. As the three parts talk to each other through defined and stable interfaces basically each part can be exchanged by another implementation. How much more modularization do you want to have? By far the most code is in the latter part of the filter (the API implementation) and of course this one can't be shared with other applications as this would require that they use the same internal implementation. But even the next big component, the Domain Mapper, is not easily shareable, as this would require that the applications shared the component model (OOo uses UNO) and the API
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Thanks, Mathias, for your time and such detailed response. See my comments below. 2008/9/26 Mathias Bauer [EMAIL PROTECTED]: Yegor Jbanov wrote: Amen to that! Plus: 1. Documentation is the suckiest thing about OpenOffice.org SDKs and APIs. If OOo has been modularized, then nobody ever noticed. May be because it's always easier to maintain prejudices than to actually check them against reality from time to time. I don't say that OOo is perfectly modularized, but it's also far away from being a monolith. As I explained in my reply to Rene IMHO people tend to think that just because one particular aspect of modularity is not visible that their can't be any kind of it. And that's not true. Maybe we use different definitions of module. My definition is close to one from Wikipedia (http://en.wikipedia.org/wiki/Module). This is how they define it in Maven, IntelliJ IDEA and Eclipse (although in Eclipse they call it project). You can already tell I'm a Java guy. Anyway, the core elements are: well-defined interface, well-defined dependencies, interchangeability, self-contained component. I am not arguing that the code might already be well-organized so that it looks like it's modularized. At the minimum a module must have a name, a separate source code tree, separate unit tests, separate documentation, separate download and a separate build script. Modules that depend on other modules must explicitly declare their dependencies. Pretty much any well-written source code in the object-oriented world that does not have circular dependencies among classes and namespaces (packages in Java) is implicitly modularized, because class/namespace references can be presented as a tree, and each subtree can be viewed as a module. A subtree can be compiled and unit-tested independently of the rest of the source code. This is good, because it makes the code base more readable and easier to maintain. As a result it is easier to maintain higher quality and richer feature set. For small projects this is usually enough. For projects of such massive scale as OOo, however, it is definitely not enough. I would say it is desperately not enough. Today office automation faces much more diverse and complex requirements. A single office suite does not meet these requirements. This is even true for MS Office. That is why they supplement their suite with Sharepoint and I am sure more is coming. OpenOffice.org is missing a server-side component like that. And that is not the only example. The age of cloud-computing is looming and OOo is not prepared for that (Google Docs, Salesforce, Zoho, etc). Is there a module dependency diagram anywhere? (This was a rhetorical question, of course.) We need a central, comprehensive, well-organized and up-to-date documentation web-site (take a look at how Google documents their toolkits). The official documentation is so badly organized/out-of-date/incorrect/incomplete that even Google fails to find relevant information. My major source has been so far the mail archive where people report their questions and sometimes get their answers, yet nobody ever cares to update the documentation so that others could find it easily. 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. 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. 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. 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.
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi, Bernd, Le 24 sept. 08 à 17:44, Bernd Eilers a écrit : Kay Ramme wrote: Hi there! Hi Charles, [... snip ...] did you see Leonard Madas Grand Vision document yet? http://wiki.services.openoffice.org/wiki/User_Experience/ Grand_Concept Just went through that thing just to still find the same old prejudice about our internal architecture. Am still thinking that anyone who still comes up these days presenting with that 'new(?) idea' to split up the than in such new(?) concept strategy so called 'monolithic-OOo' didn´t understand the concepts of shared libraries of modern operating system and didn ´t understand the basic concepts of UNO and OpenOffice.org's component model. Just to repeat that here for the few-hundred-and-and-a-dozeneds- times for those who still do not know: just because there is one soffice executable and a shared framework to open documents for all OpenOffice.org modules doesn´t mean every functionality available has to be loaded on startup at once. It´s all already 'modularized' and there do exists already ongoing efforts to split up the installation files into packages which depend of each other - been there done that! - so what? This is not something that is such a great new idea that we would not already working on since a long time. Also I do not currently see why to bring concepts like the Lively Kernel into play when talking about dynamic content in Impress or other modules. Impress and other modules already have an API that you can program it with which is defined in UNO and available to all supported programming languages which have a language binding available for UNO. I more and more get the feeling that there´s a strange kind of battle going on these days named something like on which virtual machine and API´s do you want to run your virtual machines and API´s today? or Here´s the right stack to use for your stack! After all if I want to extend something like impress with dynamic content features I just need SOME sort of API to do so and preferable support for some programming language which I can know how. Why care whether that is something based on UNO and OpenOffice.org existing UNO API´s and the existing OpenOffice.org extension features plus a few possible future enhancements thereof or something tight to a new API on top of some other new API based on javascript and SVG/HTML support in firefox or on an new API based on top of installed java support or an API based on top of installed Flash support or an new API based on support for IE and Active-X controls being there or whatever/. Mind joining us? http://wiki.services.openoffice.org/wiki/Pinneberg Best, Charles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
