Re[2]: [Octal-dev] porting thoughts

[ccastiglione]

>> Possibly, though doesn't CORBA require all senders / recipients to be 
>> objects?
> Yes, CORBA is for OO languages (C++, Java, Smalltalk, etc.). Above
> all, it's quite slow.

Well "slow" and "audio" don't mix well, so... :)

>> I was thinking ... messages as text strings
>It seems a good solution. More, text strings are system-independent,
>thus you can run OCTAL core on Linux PC and work on a Sparc
>system.

Yep, we use this approach with the CIM systems where I work, and we've got most
servers running on *nix, but client GUI's in X, VB, HTML/perl and now we're
starting in on Java.  The nice thing with the message-based mechanism is that
despite the changes in UI technology, the servers have remained untouched (well,
not touched for UI-related reasons anyway).  There are even tester machines
connecting to servers on the message bus indirectly via TCP or UDP, and they're
running DOS!

>It's the main issue of such a system. Refreshing screen could
>take hours for a big amount of displayed data (think about a
>zoom-out of the score). Having smooth scrolling is very
>important to work comfortably.

Right, it means that you must carefully separate the functions which are
strictly UI related from the fuctions which are strictly audio related, so that
you only have to pass messages when a change occurs that absolutely requires
communication.