development ideas (was Re: where is corba?)

[Miroslav Silovic <silovic zesoi fer hr>]

sopwith@redhat.com (Elliot Lee) writes:

> There wouldn't be any reason to switch implementations. libwww provides
> both a modular framework for registering and using protocol handlers, and
> implementations for commonly used protocols (http, ftp, news, file, etc.).

Actually there is another problem. libwww is C-specific, and to use it
from another language requires glue code. While this is 'just another
lib', right now when you bind GNOME to another languange, there is
large number of libs that need foreign function interface. While
binding each particular lib is easy, the sheer volume of the work
becomes formidable - and then version tracking comes into play.

I think this is a serious problem, because I see GNOME's language
independance as a major feature. So I think that some form of
automated language binding generator is called for. Some language
bindings actually already have one in place - so I think it would be a
boon to write unified specification of GNOME APIes (ones that aren't
covered with CORBA) that could serve as a base for binding generators.

There are several issues that make information stored in headers
insufficient for this:

- Some GNOME function take glist to form a sequence. But they don't
  specify the object type that glist points to, which makes
  typechecking impossible for Guile or Perl. Some other functions
  take sequences in two-parameter form:
  ElementType *ptr, int number_of_elements
  And in some cases, pointer signifies storage for data return

- Headers don't specify *meanings* of the fields in GNOME
  datastructure. For example, they don't tell how to create/copy/free
  things (and for things like GnomeHelpMenuEntry, there is no way
  to instantiate/free the struct).

So I think it would be great to have files like libgdk.glue,
libgtk.glue, libgnome.glue, or even libxml.glue that are current GNOME
releases and contain enough information to bind GNOME to any
particular language without the pain of going through the entire API
and specify each function. Files from gnome-guile could be a start.
>From these files it would be easy for the language binding maintainers
to implement a specific binding.

On another note, once GIMP introduced script-fu and gimp-perl, there
came out some really useful scripts that probably took very little
time to write. And then there is GIMP plugin system. Which gives
another idea for GNOME: most of the GNOME apps I see in the app list
on www.gnome.org are just that - applications. It would be nice to see
*small* scripts (in guile, perl, python or whatever) and small C apps
that automate simple things and perhaps interoperate with other
similar scripts. With things like dialog cauldron and Canvas and
gnome-db it should be possible to do some real work in 100 lines of C
(and even more work in 100 lines of Perl).

Organizational issue would be forming GNOME applet registry (similar
to GIMP plugin registry), GNOME script registry and, of course, ORBit
component registry.

-- 
I refuse to use .sig