Re: layers of abstraction, and how Gnome can win

Well, initial thaughts, GNOME tries to support all unicies, but not
nessisarily non unicies. glib and gtk on the other hand are attempting to
support all platforms. Most of the abstraction layers that StarOffice uses
could be stripped off and just use gtk/glib. It would slim down StarOffice
by a great deal and would help code reuse. If glib doesnt support
something StarOffice's abstraction layer does, it would be much easier to
add that support to glib rather then continue to maintain an equivalent
lib. As for bonobo, I also think this should be used in StarOffice.
StarOffice is useing its own component model in an attempt to provide a
component model that will work with all other component models. But in
reality, it would be just as easy to bind bonobo to com then it would
to bind their own special component model to com. So, my suggestion is to
use glib, gtk, and bonobo for StarOffice.  The only thing that would be
lost converting to those technologies is alot of duplicated code. :)

On Sun, 10 Dec 2000, Brian Behlendorf wrote:

> Note: though I am a vendor to Sun on the OpenOffice project and have been
> looking at these issues for them under contract, I in no way speak for
> Sun, OOo, Apache, or anything other than myself.
> One of the subtle nuances in the "what is gnome office" thread that didn't
> get explicitly discussed is one of layers of abstraction.  I believe this
> is the fundamental difference between the Gnome and OO projects, and I'd
> like to point out how by asking a few questions:
> a) Is it the mission of the Gnome project to create the best free (as in
> free-speech) desktop for Linux?  Or is it to create the best free desktop,
> period?  I use FreeBSD and Gnome on my Vaio, and it's great - I've never
> come across a bug in a Gnome app that struck me as being due to that app
> not working on FreeBSD.  And clearly Sun and HP wouldn't have lept onto
> the bandwagon if getting Gnome working well on Solaris and HP-UX wasn't
> also not only permitted, but encouraged.  So I presume the answer is that
> Gnome aims to be the best free desktop for all Unices... but what about
> Windows?  I'm aware of the gtk-win32 port (yay!), but what about running
> an entire Gnome desktop on top of a win32 kernel, replacing Explorer?  Or
> on MacOS X/Darwin, replacing Aqua?
> b) Is it Gnumeric's mission to be the best free spreadsheet out there,
> whether you're using KDE or Gnome or even just a bare windowmanager?  If
> someone contributed a series of patches to get Gnumeric to compile cleanly
> and look nice under Win32 native widgets, would they be accepted?
> As far as I can tell, OpenOffice aims to be (er, Sun aims it to be) a
> truly cross-platform office suite.  Many, possibly most of the developers
> in Germany are clearly developing in a Windows environment.  Like Mozilla,
> they went through great pains over the last couple years (I've heard 10
> years from one person) to create their cross-platform suite of portable
> APIs they can write the core library of apps with, an environment they're
> now pretty comfortable with, though it of course represents a substantial
> learning curve to outsiders.  (That's not deterred patches from a couple
> dozen outside contributors in the first two months of the project, some of
> them fairly newsworthy bug fixes).  This affects everything - object
> component system, UI, even things like string classes.
> Today, OpenOffice at least has some hope that it can run consistantly
> across Windows, Linux, and Solaris, the platforms that Sun developers
> target.  It used to run on many more (a point of pride for the German
> developers, I was told, was when a new processor or OS would be announced
> and an OO port was available within days) but I believe they are focusing
> on those three, leaving others to the community; there have already been
> substantial patches offered for a freebsd native port, SGI, and
> linuxppc.  But those all are platforms which do or should run Gnome, it
> sounds like.
> So the fundamental question is, if a company wants to develop a
> cross-platform app, cares as much (if not more) about running on Windows
> and non-Gnome-supported Unix-like OS's, as they do on platforms covered by
> Gnome, what should they do?  Both Mozilla and OpenOffice are, by inertia,
> choosing to maintain their cross-platform infrastructure in order to meet
> this need, and any interfacing to Gtk or Bonobo will probably be in
> the form of compatibility layers and bridges instead of core
> architecture.  This is clearly not optimal - it bloats the apps
> tremendously and makes for a whole lot of repeated work.
> They could do what the Gnome hackers have asked - rip out anything that
> resembles functionality already in the Gnome universe and replace it with
> its Gnome equivalent.  I bet that would strip it down to a much smaller
> size, improve performance, etc etc.  Or someone could pull a Galeon and do
> it on them, though I suspect the code's complexity at this point would
> dissuade anyone from trying.
> But if they did that, if they really adopted Gnome as whole-hog and
> single-mindedly as the office apps that came from within the existing
> Gnome community have, then they'd lose the ability to run on Win32.  I
> don't speak for Sun or the development team in Germany, but I suspect that
> Win32 support is important enough that this would be a non-starter.
> Why care about Win32?  And why am I writing about Win32 on a Gnome list
> anyways?  Because I believe part of the reason why Sun (traditionally not
> an end-user software company) launched the OpenOffice project and has
> several dozen engineers dedicated to it is to commoditize the market for
> office software in general.  Recognize that Microsoft makes over half of
> its gross revenue from Office; and that due to the commoditization
> of the OS thanks to Linux, Office is today a bigger monopolistic force on
> the enterprise than Win32 is.
> I believe a similar mentality would be good for the Gnome project to
> adopt; that bringing the Gnome api's and components to Win32 is not only
> an interesting project worthy of support, but that when resources are
> available, they are applied towards that goal, that the cause is advocated
> whenever possible, and that engineers with Win32 experience are not made
> to feel like second-class citizens.  Let's turn embrace-and-extend back on
> Microsoft - let's get Gtk, Bonobo, and other infrastructural pieces solid
> on Win32.  We'll have to do the same thing to counter the .NET proposal,
> but that's not for awhile.
> We've done this in Apache now - Apache 2 will run as well on Windows and
> OS's like BeOS and OS/2 as it will on Unix thanks to abstracting all
> system-level issues we care about into a library called "apr" (Apache
> Portable Runtime, kinda like Mozilla's NSPR but specific to servers and
> Apache-licensed).  This is partly because the core server
> developers were happy to specify an API (posix-like), and companies like
> IBM and a couple motivated developers were willing to do all the work
> necessary under that API to translate it use the most appropriate native
> calls, implementing new functionality as needed.  If Stallman and I can
> resolve our BSD/GPL compatibility issues, then it's something Gnome could
> use as well, though we don't touch UI issues at all.
> Yes, I know the typical answer whenever an outsider lectures an open
> source project on what they should do: "we await your patches". What I'm
> asking here though is much more about policy and leadership than specific
> code suggestions.  Maybe this is all actually happening and I don't
> know; if so, great!  But let me tantalize you with a thought: Gnumeric
> running on Windows, and Windows users suddenly able to use a desktop and
> office suite much more interesting and free than what they can choose from
> today.  This is how Gnome can win - not just over KDE, but over that other
> OS.
> Thoughts?
> 	Brian
> _______________________________________________
> foundation-list mailing list
> foundation-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]