[Coco] Your stock CoCo is DriveWire-ready out-of-the-box (was: DriveWire for dummies?)
jcewy at swbell.net
Thu Dec 24 15:30:14 EST 2009
Aaron Wolfe wrote:
> On Wed, Dec 23, 2009 at 2:17 PM, William Schaub <wschaub at steubentech.com> wrote:
>>> Speaking of DriveWire Java Server, I'm running the Java server on my eMac
>>> and it is performing quite nicely. If Jim is successful in developing a
>>> web-based front-end that works on all three major platforms (Win, Mac,
>>> Linux) then I think it will be time to abandon the platform specific servers
>>> and focus efforts on the Java version.
>> Just my 2 cents but I really don't like web interfaces at all. why not just
>> use the java swing library and be done with it? I know it will look
>> different on each platform due to how java works but as long as the GUI is
>> usable who really cares? I dislike very much having to load a heavy weight
>> browser just to use a utility like the drivewire server.
Depending on what your objection to the heavyweight browser is,
something like Prism ( https://wiki.mozilla.org/Prism ) might or might
not make it more palatable.
> I'm doing the "backend" portion of the server, Jim is doing the web
> GUI. One thing I've ensured is that the Java DriveWire server is
> usable without any gui at all. The backend portion provides hooks for
> a GUI to manage it, but these same hooks can be called in other ways.
> For example, there is a new utility that runs on your CoCo which lets
> you switch disks, configure ports, or view DriveWire status right from
> the NitrOS-9 command line. With this tool, you can manage all your DW
> settings from the Coco itself.
> It would be possible, maybe even easy, to add a Swing or SWT GUI. I
> initially planned to do so and packaged the .jar with an SWT GUI, but
> the GUI part seemed to be a hindrance to portability. Right now, the
> server code in .jar form can run on Mac, Windows, Linux, even a
> Linksys NAS device. If I add GUI components, it seems I must build a
> different .jar for each target platform, and with everyone being split
> between 32 and 64 bit right now means two .jars for Mac, Win, and Lin.
> 6 different files just to support our main targets :( not to mention
> that each one's GUI looks entirely different.
> By using Jim's web interface based on the Google Web Toolkit, not only
> do we get a consistent look and feel across platforms, but we still
> can give out a single .jar that runs on all targets. A web interface
> also means the interface is accessible from a remote host. This is
> more important now that the DriveWire server also has the ability to
> let you access the Coco from a remote host. The web interface may
> even include OS-9 terminals at some point.
> The final benefit (that I can think of) from the web interface comes
> to light when you consider running the DriveWire server on a tiny
> device like the Linksys NSLU2 or even some of the tiny x86 boards
> being discussed on the list lately. They don't (or may not) have any
> video output capabilites, yet using a web interface they can still be
> a very nice (and tiny) DriveWire server.
> By using a web interface, basically any device that runs Java and has
> ethernet or wireless ethernet becomes a potential target for running
> DriveWire server. I think this opens up some really interesting
>> But then again I'm not on the development team or anything so my opinion is
>> not likely worth much more than two cents anyway. :)
> It is valuable to know there are other opinions, but I think at this
> point we'll continue with the current direction unless a major problem
> arises. You are more than welcome to add a Swing GUI at any point,
> the code is in the DriveWire sourceforge CVS and I'm happy to answer
> any questions you have or offer help where I can.
>> Coco mailing list
>> Coco at maltedmedia.com
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco