Opentalk for ObjectStudio

Len Lutomski and Andreas Hiltner are up with the new Opentalk for ObjectStudio stuff - they'll have a live demo of VW <--> ObjectStudio interoperability. Cross platform as well, with the VW side running on a Mac.

So, There's a demo of a chat application (shipping on the CD) - and they'll go over the cross dialect portability issues. First, what's Opentalk? Opentalk is the framework used in VW for the creation of communication protocols. ObjectStudio 7.0 contains a release quality version of Opentalk ST-ST (Smalltalk to Smalltalk). ObjectStudio was extended quite a bit to achieve this - the upshot is that Opentalk in ObjectStudio is identical (at the user level) to Opentalk in VW - so user code will move between the two easily.

ObjectStudio now supports multi-image applications, including VW images on non-Windows systems. This extends support for OST features to VW users, and of VW features to OST users.

Now they are showing the demo - chat windows on Windows in ObjectStudio, and their analog over on the Mac in VW.

Len's now going through some basics. Three topics:

• request brokers
• initial references to remote objects
• pass modes

This stuff is all discussed in the doc. A request broker implements the API of interest to applications. A protocol implementation consists of

• an adaptor - mapps ST messaging to a protocol type
• a transport - implements transport layer (e.g., TCP)
• a marshaler - marshals/unmarshals objects onto/oof the wire
• a dispatcher - regulates message handling on either end of the wire - typically process per message

Creating a broker (you can specify the address for systems with more than one network interface). A broker is actually a fairly complex object - the simple API below flares out to define all the parts described above (adaptor, transport, marshaler, dispatcher). That means that you can customize these parameters, or derive your own protocols and slot them into this api easily.

"create it"
broker := RequestBroker newStstTcpAtPort: 1900.

"start the broker"
broker start.

"stop the broker"
broker stop.

Now, why would you want to customize the dispatch? In VW, a new process is just a lightweight VW process. In OST, it's a Windows thread. That could tie a Windows system down quickly - you'll want to configure pool dispatch. There's some basic protocol for testing connections - echo and ping. Echo sends an object across and then gets it back. So you test marshal and unmarshal on both ends.

Now, to actually accomplish something you need to reference some object on the remote side. A reference is a local proxy object that re-implements doesNotUnderstand: to forward messages. When you send a message to a reference, you are sending it across the wire. There are two ways:

• Programmatic construction
• Server registry

"create"
broker objectAdaptor 
	export: someObject 
	oid: #greeting.

"reference remotely"
remote := clientbroker 
	remoteObjectToHost: 'localhost' 
	port: 1907 
	oid: #greeting

"server registry"
broker registerService: Random new id: #random

"client"
remoteObject := (clientBroker
					activeBrokerAtHost: 'localhost'
					port: 1907)
				serviceById: #random.

What about pass mode control? Pass mode is how it's transmitted - for instance, by reference or by value. Copying a large object across the wire can be expensive. Passing by reference is cheap, but messaging that object may be expensive. You need to balance the two. By default in Opentalk, most things (not immediates, literals, few others) are passed by reference. You can override that at the class or instance level - there's an API to coerce the pass mode. You can customize down to the instance variable level if desired. Opentalk supports several pass modes and pass mode controls - check the documentation.

What about cross dialect issues? You need to be aware of them - they are all documented. Base classes are mapped already - so VW and OST collections pass between each other seamlessly. There are some disparities in Magnitudes:

• OST Decimal, VW FixedPoint
• Float/Doubles (ObjectStudio only has the equivalent of the VW Double)

The error messages coming from OST and VW will differ as well (i.e., the error strings from things like MNU, for instance. That wraps things up, and unfortunately, time was a little rushed. I think a number of people are going to want to see this in the demo room later. Another upshot - having done this, porting Opentalk to ObjectStudio means that it should be fairly easy to port over to other Smalltalk implementations.