[Coco] Your stock CoCo is DriveWire-ready out-of-the-box (was: DriveWire for dummies?)

[Aaron Wolfe]

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.
>

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
stuff.

> 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
> http://five.pairlist.net/mailman/listinfo/coco
>