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 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
