GNOME platform as either/both JVM and CLI and more



I've been following the discussion of whether GNOME should move toward a
Java Virtual Machine (JVM) or a Common Language Infrastructure (CLI)
virtual machine with some interest. I'll stay out of the actual
discussion of which one is preferred but I have a few more general
questions which might serve as movements toward either/both (and more).

If I understand the discussion so far there is agreement that Java/JVM
and C#/CLI will both be around for sometime and are fairly compatible.
In this context people have mentioned the Portable.NET C#->JVM compiler
and the IKVM JVM translator for Mono as means to allow C# to be used
with a JVM and Java to be used with a CLR. Assuming that either/both of
these options would work I'm assuming that the understanding is that
they could then share bindings of the C libraries which currently form
the GNOME developer platform. In this case shouldn't Java-GNOME and GTK#
have fairly similar APIs? Starting from the imports (org.gnu.gnome...
for Java-Gnome and Gnome... for GTK#) and into the individual classes
there is significant divergence already. As a first step toward
potential, future cooperation would it help to start trying to unify
things in this area?

Richer GObject introspection as Havoc suggested may help provide a
clearer base to allow more consistent mappings. But since each language
should try to map the platform to the most native language semantics
(ie. C# delegates) even in virtual machine environment doesn't every
language need to have its own bindings generated? And if this is the
case what really is the big win for a VM? Something like C# obviously
removes some tedious C coding and adds a garbage collector which can be
useful sometimes but isn't the multiple languages within one VM a little
overhyped? For instance, despite the potential of a VM to do more, JVMs
currently can (realistically) do Java (and maybe Jython and Groovy?) and
Mono currently has C# (and maybe IronPython?). I can't think of an
extremely clear example at the moment but try this one: suppose you use
some language which stores two-dimensional arrays by the first index and
then by the second index
	some_array[2][3] = ([0][0]),([1][0]),([0][1]),([1][1])...)
which is then exposed over the VM. Now if this is used in another
language which stores two-dimensional arrays by the second index and
then the first index instead aren't we going to have a serious
performance mismatch between the way the same API is executed between
the two languages because the API was designed specifically for the
features of the one language? And if not isn't the VM just reducing
languages to a single language with multiple syntaxes? For instance in a
CLR won't everything either be C# or be forced to move toward C# designs
for performance reasons? Even the in the IKVM case there must be
overhead in transforming C# types in the ECMA core into Java native
types, isn't there? This holds true in many respects for C/GObject APIs
with bindings as well. Which leads me to my third point: if the final
idea is to make a unified GNOME platform what will it look like in each
language and how do you make divisions between language syntax, language
conventions and standard language libraries?

People have been claiming we could use Classpath + a JVM/GCJ or ECMA + a
Mono CLI but that seems sufficiently high-level to not mean too much to
me. After all Classpath is more equivalent to ECMA + .NET since it is
attempting to implement a J2SDK 1.4. To give a concrete example: should
a Java GNOME application use the Java XML apis or a wrapped libxml2,
should a C# GNOME application use the ECMA XML apis (if they're even in
the core)? Another example would be data access: does a Java GNOME
application use JDBC? does a C# GNOME application use ADO.NET?

Answering both what the GNOME platform is and what does the GNOME
platform mean within each language seems to me to be a prerequisite
before discussions about which are the favoured languages can begin.

Here's a very brief list for starters on what could conceivably be in a
platform. I think it could be the start of some discussion.

* Users & Groups
  * Authentication
* Compression
* Cryptography
* PKI infrastructure
* Data Access
  * XML
  * Relational Databases
  * LDAP
* GUI Widgets
  * ie. GTK+, Qt, XUL, wxWidgets, WINE, Windows.Forms, Swing, SWT, FLTK,
Tcl/Tk, Motif, VCL
* Typography
* Display
  * 2d raster
  * 2d vector
  * 3d
  * video
* Configuration & Preferences
* Culture
  * Internationalization
  * Localization
* Files
  * URL handlers (ie. gnome-vfs, kio, fuse, avfs, lufs)
  * more metadata (ie. storage, medusa, iFolder)
* Audio (ie. OpenAL, ALSA, MAS, Jack, GStreamer)
* Voice production/synthesis
* File Formats
  * Image Formats
  * Audio Formats
  * Video Formats
* Printing
* Input Methods
  * Keys
  * Pointers
  * Pen recognition
  * Speech Recognition
* Video
* Presentation
  * Web
  * SMIL
  * SVG
* Communication
  * EMail
  * IM
  * VoIP
  * video conference
  * Fax
* Network libraries
* System Abstractions
  * OS/Kernel/Distribution
  * Hardware
  * Service discovery
* Application communication/components
  * ie. CORBA, Bonobo, D-Bus, XPCOM, UNO, DCOP, KParts, XML-RPC, SOAP,
.NET remoting
* Synchronizing
  * addressbooks, calendars, phones, handhelds, laptops


end.
patrick




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