David:
There are a few options shy of redesigning the abstractions in the VM for
the CLR, which may or may not be feasible - I think not, for several
reasons, most of them related to the memory model.
It is a myth to think that the different .NET languages really give you
meaningful semantic alternatives. A language in .NET is little more than
syntax sugar on top of a single semantics - namely, the Common Language
Specification, or CLS (a subset of the CLR) - a semantics that is
singlemindedly object-oriented, even down to the "assembly" langauge (IL),
and strongly typed. This isn't to say it cannot be done - but one of the
victims of being successful at creating a runtime environment suitable for
Oz's multiparadigm semantics in the CLR would likely be the very
interoperability between languages that is its "strong suit". Or, Oz may
have to adopt some of the CLSs data types and type rules which could very
well break everything Oz is about.
The most obvious candidate for a "tightly coupled" integration, rather, is
to look into creating a COM "wrapper generator" for the Oz emulator; better
still if it can wrap individual functors as "ActiveX" objects. .NET-COM
interoperability is probably your best bet, especially while that
interoperability is a major focus of .NET right now. (People are slow to
give up all those millions of lines of code to march boldly into .NET and
would prefer to build .NET apps that leverage existing investment in MS's
previous component architecture).
Python's COM integration on Win32 is worth researching, toward this end.
I can see at least two major new options for ozc:
-ole : create this functor as a COM DLL (in-proc COM server)
-olex: create this functor as a COM standalone exe (out-of-proc COM
server)
Now things get tricky because you'll want to use the MS compiler for the COM
wrapper part. Cygwin and MingW will let you create COM *clients*, but the
creation of COM servers is not, I think, supported. But the MS compiler, due
to lacking "computed gotos", generates horribly inefficient code in the
emulator's main "switch" statment when you use standard workarounds, so
compiling the emulator using the MS compiler has proven more pain than gain.
(This "computed goto" problem is not a problem only for Oz; the OCAML
distributions for Windows also have notes about this - the MS compiled
verison is on the order of 30% slower than the Cygwin and MingW
distributions on account of it as well.)
Changes to the emulator are likely required to make it expose everything
you'd need for your COM wrapper in MS to "talk" to the emulator using
standard C calling conventions. And the threading options for COM may prove
hard to reconcile with the emulator. </understatement>
Once you were successful with that, then you may need to worry about things
like generating proxies/stubs, typelibs, and a bunch of other COM
dissiderata.
But once you *could* create COM servers out of Functors or the emulator
itself, .NET already has the tools needed to "wrap" the COM object in the
CLR and generate wrapper assemblies. So in the end you'd have .NET wrapping
COM wrapping the Oz emulator invoking a functor in a very non-Oz way. Don't
expect anything close to the type of performance you get out of Oz natively.
Another, simpler, "loosly coupled" option is to create an application server
for Oz that will let you create functors as "Web services" which are
basically components, only they communicate with their clients via SOAP over
HTTP - also not exactly the most efficient means, but it avoids all the
gnarley COM issues and the even gnarlier CLR issues. Moreover it preserves
Oz semantics and gives people a meaningful alternative to J2EE and .NET on
the middle tier and on any platform... an idea I expressed on this list
awhile back.
That isn't to say it isn't worth it - if you need any volunteers to help,
let me know. It is a very interesting challenge and I've given it a lot of
thought. I wish I had your job!
Of course the best option, if network transparency is the big plus and you
dig the multi-paradigm semantics of Oz and you need a *lightweight*
framework for pocket PC applications is to implement the application 100% in
Oz, and communicate with .NET web services only when you need to exchange
data or other functionality. For your problem domain, this is what I'd
advocate, no matter how interesting the COM wrapper/CLR integration might be
on their own.
- Bob Calco
Medical Manager R&D
----- Original Message -----
From: "Leif Kornstaedt" <kornstae@ps.uni-sb.de>
To: <hackers@mozart-oz.org>
Sent: Wednesday, October 08, 2003 6:42 AM
Subject: FW: Mozart.NET
| I'm forwarding this to the hackers list - David accidentally
| only sent this to me.
|
| -----Original Message-----
| From: David Bouvy [mailto:dbo@BizzDev.com]
| Sent: Wednesday, October 08, 2003 12:19
| To: kornstae@ps.uni-sb.de
| Subject: Mozart.NET
|
| Hi. Sorry for the delay. As you know I'm working on a project which
consist of porting Mozart on .NET. My company wants to create
| .NET Components based on Mozart, specialy the concept of distributed
application. My company carries out lots of mobile applications
| with pocket pc which can be connected or not. So the network transparency
present in Mozart is very interesting in that case and
| this is the goal I want to reach. Can you tell me some advice and maybe
the different steps I'll have to realise.
|
| David Bouvy
|
| -
| Please send submissions to hackers@mozart-oz.org
| and administriva mail to hackers-request@mozart-oz.org.
| The Mozart Oz web site is at http://www.mozart-oz.org/.
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.