I've been thinking about using Mozilla and its component architecture
for a particular project for some time, and I've decided what I need to
add to meet its requirements. The reason for this post is to see whether
anyone thinks that what I have in mind would be generally useful (ie.
code should be offered back into the Mozilla project) or whether its
something I should "keep to myself".

General info
=========

To start with some general background,  my application  is to be a
cross-platform software framework for all sorts of purposes, both client
and server, where functionality is added in the form of components (I
call them "plug-ins", but this isnt to be confused with plug-ins in the
normal browser sense - there's no web browser or server here) each of
which follow a general form.  These plug-ins must be able to talk to
each other, even across machines (eg. using XML-RPC or something similar
as the transport) by exchanging "messages" (ie. just calling defined
methods with defined parameters). Some plug-ins will have a real-time
nature, eg. operating some physically attached electronic equipment,
some wont.

The plug-ins may be written by different companies, in C++. They will
each have their own purposes and user interface requirements, usually
simple dialog boxes, which the framework will support through some form
of XML-based UI specification (like XUL). Also, it would be nice to be
able to script the plug-ins within the framework in a generic way.

>From the above it should be obvious why Mozilla caught my eye!

Extensions
========

However the application also requires some things which dont yet come
with Mozilla and its parts ( XPCOM, XPCONNECT, etc):

1)  Very loose coupling of (often complex) data types passed between
plug-ins, so changes have minimal consequences,  and run-time
setting/discovery of data format/content (more akin to VB or scripting
than C++)

2) Some means to allow message communication between plug-ins both
within the same application instance (efficient) and between machines
(less efficient, eg XML-RPC, SOAP, whatever).

3) "plug-ins" to exist as shared libraries (as normal) or as separate
processes. The latter for overall robustness - one thing crashing should
not take down everything.

Full Solution
=========

Initially I thought about extending the Mozilla IDL, XPCOM, XPConnect
and Javascript engine to allow XPCOM componentry (and scripting thereof)
to work across processes amd machines where desired. However this "full
solution" looks like a massive undertaking (not yet started by anyone
else), and I don't necessarily need this anyway.


Planned Implementation
==================

Instead, I'm thinking of the following, more simple approach:

a) Using only one C++ data type (I call this the 'XVAR" class) to
communicate between plug-ins, but making this able to represent
virtually any data type,  like a "super, multi-dimensional variant".   A
single XVAR can hold a single scalar type (int string, etc) or an array
of XVARs (indexed by ordinal or arbitrary string), which recursion then
allows a single XVAR  to represent a data structure of arbitrary
complexity. XVAR objects can persist themselves to/from XML
(inter-machine passing with XML-RPC/SOAP/etc) and a more efficent binary
format (efficient intra-machine passing). eg:

   XVAR xv;
  xv[0] = 1.23;
  xv[1] = "Hello";
  xv[2]["First"]  = 1;
  xv[2]["Second"]  = 2;

I already have this class from some other work (it also has a variety of
methods for managing internal content, eg. controlling whether or not
scalar types at XVAR leafs can be changed by assignment).

b) Providing an XPCOM-implemented proxy  to allow calls to any XPCOM
component (locally or on any machine,  library or process-resident)
which passes and returns exactly one XVAR . This will require extensions
to other things, like NSPR (IPC), XPCOM, XPConnect, IDL, etc, but
nowhere near that needed for the full solution (which would require
extending these things to near Corba/ORB levels).

c) Giving Javascript the ability to manipulate  XVARs and call the above
proxy. Hence script on one machine can interact with any "XVAR object"
on any machine. Unfortunately the first  part of this would be messy
since Javascript doesnt support string-keyed arrays (as far as I
remember from years ago!).

Does anyone think this would be generally useful, at least until the day
that XPxxx gets full distributed object support (if ever) or should I
keep my stupid idea to myself !??! :-)

Cheers,
Chris

















Reply via email to