[ruby-talk:7355] Re: A Java Developer's Wish List for Ruby

Dave Thomas writes:

# "Conrad Schneiker" <[e-mail]> writes:
# 
# > Well, AFAIK, getting the XPCOM bindings done is the first step. 
# 
# Not having following the Mozilla stuff at all, could someone help me
# out here.
# 
# If we just wanted to use the UI stuff, but without Gecko et al, do we
# need XPCOM, or do we just link to the stuff in the widget tree
# (nsButton and so on)?

I don't know, but I just found this
(http://www.mozilla.org/xpfe/xptoolkit/introduction.html)
for the group's consideration:

============================================================
The XPToolkit is a collection of loosely related facilities, from
which application writers can pick and choose, which provide a
platform independent API to some commonly exploited platform-specific
machinery, e.g., bringing up a dialog. Not all platform independent
facilities fall under the XPToolkit. JavaScript, for example, is a
distinct service. Not all the platform specific implementation details
can be forced into the XPToolkit. Applications will still contain
platform specific code, though they can minimize the amount by
exploiting the XPToolkit. 

 The primary facility we will provide is that of instantiating
 windows, dialogs, and other hunks of user interface machinery from an
 XML description. The description will, hopefully, offer equivalent
 and broader power over the UI than currently supplied by HTML.
 Allowing UIs to be constructed entirely from XML and JavaScript
 significantly lowers the bar for UI builders. An application built on
 this service has the choice to expose it to end-users. This opens up
 many possibilities including, e.g., `downloadable chrome', personal
 customization, etc. 

 Making UIs as easy to construct as web pages will open up UI
 evolution to the same massively parallel development that has so
 richly benefitted open source code. 

 A client that doesn't overlap the services provided by the toolkit
 will have a (hopefully, itself portable) kernel of code that does all
 the non-UI things the app does (like speak http, or implement a
 database). Along side it, or wrapped around it will be a scriptable
 interface, e.g., as defined with the XPIDL and XPCOM. The script
 support provided by this interface will be sufficient to query and
 set any parameter, or issue any command, that the UI traditionally
 would have viewed, changed, or issued. 

 Somewhere accessible, stored in an application specific form, are
 hunks of UI description---streams of XML---corresponding to hunks of
 UI machinery. The app might store these descriptions as individual
 files; as resources; as database entries; or even remotely to be
 accessed through URLs. Whenever some piece of UI machinery must be
 instantiated, the app serves up a stream of XML to the toolkits UI
 poser; and the UI machinery comes into being. 

 This separation is, of course, older than the hills. It is the
 Model-View-Controller paradigm touted since Smalltalk days, and in
 many application frameworks since. Because the app kernel has no
 knowledge of any particular dialog, window, or menu, it is totally
 uneffected when the UI designer moves facilities from one dialog to
 another, or changes their form completely. 

 This facility alone, helps us build applications faster because our
 UI builders don't have to wait for our application engineers. We can
 do even more, however, if we don't `harden' the interface into the
 built application. The application can expose its interface
 descriptions to end-users at any level from selecting pre-built
 alternative `themes', installing entirely new facilities (e.g., from
 Netcenter), downloadable chrome, locally customizable chrome, right
 down to giving the user ultimate power over every pixel of the UI.
 What level to expose is entirely up the application. 
============================================================

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)