Interoperability under Windows (Was: [Oz] Oz vs. Squeak)

[Bob Calco]

Denys:

# I was referring to the idea of making Oz functionality available e.g.
# through COM technology.  Repackaging this functionality so that it may
# be embedded in other applications is not a platform specific effort.

I think I know what you really mean, but as stated I disagree. Any code to
do with packaging Oz in COM cannot be used on any other platform, period.
However, creating a COM engine for Oz such that it can be used "the Windows
way" is still a very worthwhile endeavor, and it needn't do anything to Oz
itself to make it tied to the Windows platform. I think that's what you
meant, no?

# Personally, I would rather first aim to make it easy for arbitrary
# applications to communicate with an Oz process, e.g. using DCOM,
# CORBA, SOAP, XML-RPC, a direct interface to the Oz marshaling
# protocol, or whatever takes your fancy.  I believe this would be more
# robust, practical, scalable, and has the advantage that we can have it
# today.

Great minds think alike!

I've already started working on DCOM servers that encapsulate using the Oz
command line tools on a particular (Win32) machine, complete with a simple
but powerful object model, mostly so I can use them in my once-and-future
IDE (which will also be COM automation-friendly), but also so that they can
be kicked off using other COM client apps, like VB/VBA/VBScript/JavaScript
or any scripting engine that is ActiveX compatible (Python, Perl, etc.).
They'll have connection points for start/stop/output events so that output
can be redirected wherever (a memo field, a file, a memory-mapped file, a
named pipe, a socket, take your pick, it's totally up to the client what it
does with the output strings (plain old pointer to char) and some ability to
format the output to XML/HTML/Office Word/Excel/etc. Since I'm still
learning the tools -- not to mention gainfully employed over 70 hrs /wk on
my company's development project, and my book -- it's slow going, but I have
started the process, created projects and have some skeleton code in place.

Also, I already have, from other projects, a generic COM-friendly base class
for generating command line tool options strings and a console app thread
class that encapsulates actually kicking off an instance of a particular
console application and redirecting its output, so a little code reuse will
make things a bit easier. (I'm building it in C++ (Specifically Borland C++
Builder) since it is, literally, crazy to do it in C when you have the ATL
to make your life easier (Borland's COM implementation wisely uses the ATL).
I don't even need to POC it I just have to copy what I did in the other
project.)

I think everyone will be pleasantly surprised once I post them. I'll have a
full professional Windows install, to boot. If you don't like the IDE I
create you can always use these objects to rapidly build your own in
whatever language/technology you want. ;)

Making Oz a COM client is a wee bit trickier; some day I'll get to that too.
One step at a time...

Sincerely,

Bob Calco
Centreville, Virginia USA
rcalco at cortechs.com



# -----Original Message-----
# From: owner-oz-users at ps.uni-sb.de [mailto:owner-oz-users at ps.uni-sb.de]On
# Behalf Of Denys Duchier
# Sent: Saturday, February 03, 2001 9:09 AM
# To: users at mozart-oz.org
# Subject: Re: Interoperability under Windows (Was: [Oz] Oz vs. Squeak)
#
#
# rcalco at cortechs.com (Bob Calco) writes:
#
# > # Indeed, this would be very desirable.  However, I do not find the
# > # prospect of a purely Windows-specific effort appealing.  It would be
# > # much more desirable to plan for embedded uses of Mozart technology,
# > # with COM as one instance application.
# >
# > I don't think anyone wants to inprison Mozart on Windows.
# However, I will
# > add that making a .NET port of Oz/Mozart would be a purely
# windows-specific
# > effort. ;)
#
# I was referring to the idea of making Oz functionality available e.g.
# through COM technology.  Repackaging this functionality so that it may
# be embedded in other applications is not a platform specific effort.
#
# Personally, I would rather first aim to make it easy for arbitrary
# applications to communicate with an Oz process, e.g. using DCOM,
# CORBA, SOAP, XML-RPC, a direct interface to the Oz marshaling
# protocol, or whatever takes your fancy.  I believe this would be more
# robust, practical, scalable, and has the advantage that we can have it
# today.
#
# Cheers,
#
# --
# Dr. Denys Duchier			Denys.Duchier at ps.uni-sb.de
# Forschungsbereich Programmiersysteme	(Programming Systems Lab)
# Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
# Postfach 15 11 50			Phone: +49 681 302 5618
# 66041 Saarbruecken, Germany		Fax:   +49 681 302 5615
# -
# Please send submissions to users at mozart-oz.org
# and administriva mail to users-request at mozart-oz.org.
# The Mozart Oz web site is at http://www.mozart-oz.org/.
#

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.