Re: GNOME platform as either/both JVM and CLI and more

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2004-03-30 at 03:49, Patrick wrote:
> 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?

Yes
> 
> 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?

One binding for one VM should be sufficient for all langauges that VM
supports. With Mono, AFAIK different languages can access classes in
different languages without the glue or wrappers you would require with
non-mono ones as they share a common component framework like Delphi
components and Java beans (no need for corba, bindings or other external
mechanisms). 

>  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?).
Also VB.net and others (see the mono site pages for a full list - its
fairly numerous)

>  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? 
Mono's Common Component framework?
> 
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>