Ian,
you and the other guys had good points. Let's categorize them somehow. IMHO:
- We need to work on the channels to get OOo. These can be APT
compliant, Java Web Start, Win-Get (APT for Windows), CDs or similar.
- We need to work on the package structure. It is not optimal regarding
the distribution of the packages content and the underlying concepts
(just install an OOo on Windows while de-selecting everything, you would
still get about 200mb copied to your disk without any usable
functionality ;-). Stephan Bergmann and Ingo Schmidt are currently
working on this, one part being the separation of the URE (see
http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE).
- We need to improve the OOo software architecture, to reduce functional
redundancy etc. heading for less code with more features :-) First step
for this is to actually get an understanding what it consists of ... see
again
http://wiki.services.openoffice.org/wiki/Analysis/Source_Code_Inventory
(don't know why the page was blank for you, just reloaded it and looked
fine).
- We need to expand into new technologies. Be it Ajax, Flash,
Silverlight, JavaFX or similar. To support dynamic access to OOo
respectively ODF.
- We need to ensure that OOo keeps appealing, impressions and handling
are very important.
- We need to attract more contributors. Companies, private people etc.
This seems to be hard but very promising ...
- And, IMHO this wouldn't be enough, we also should take care of easy
distribution of ODF, just being used as mail attachments doesn't seem
sufficient ...
Regards
Kay
Ian Lynch wrote:
On Thu, 2007-08-23 at 15:29 +0200, Kay Ramme - Sun Germany - Hamburg
wrote:
Ian,
Ian Lynch wrote:
Hi,
I know this has come up before but I think one of the biggest things
holding back OOo in the market is the size of the code. I just used
Inkscape to do a flyer recently and got someone in the office to just
download and install it to print the flyer. There was no anti-reaction
yet when I asked someone to do the same on a different occasion with OOo
there was reluctance because of the size of the download and the thought
that it would somehow clutter up their computer. So its not easy to do
but we have to bear in mind that things like Google apps are going to be
a lot more palatable to some people than downloading 100 meg of OOo
code. Delivery of OOo through a web browser from a remote server might
be easier than slimming the code down. Sun's global desktop type
technology but focussed on OOo and with a simple sign up but seems more
likely to be developed as a service eg integrated with a Web2.0 business
than something the community can tackle on its own.
you are at least right regarding the code and installation size, and
some people are aware of this already. Though the page needs to be
updated, we have a project started to analyze the OOo code basis in more
detail (see
http://wiki.services.openoffice.org/wiki/Analysis/Source_Code_Inventory)
, to actually get an understanding why its so huge ...
Noticed the page is blank. Is this aspirational to reducing the code :-)
Seriously, I think the dilemma is that the shared code in OOo should
make the individual apps collectively smaller so separating the apps to
eg WP, SS, Draw, Base would overall make the code bigger unless there is
some fundamental inefficiency somewhere. Not everyone needs every
component and I should think a WP would be good enough for many.
However, if separating out Writer made it say 50% of the existing code
it probably still wouldn't be much good in improving take up so not
worth the effort. If you can get Writer down to around 20 meg I think
you are in business but that is going to be very difficult. That is why
I was thinking a web based approach might be a better use of resources.
If OOo was running server side with an Ajax type technology in a web
browser I can't see too much problem with WP/SS apps. Graphics might
become a bit of an issue but if You Tube can manage concurrent video
pretty well surely office apps can't be impossible with appropriate
local caching to smooth out latency.
In environments where tech support is lacking eg primary schools, not
having to install an office suite and maintain it locally has some major
advantages. I'm sure the people developing Sun's Global Desktop realise
this, I just wonder whether OOo access through web browsers on existing
systems might not help provide confidence to move on to more radical
change such as remotely provided thin clients.
Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
