Re: HALManager idea ?

[John B]

Hi Rob,

> I've been exchanging email with Ian all day and apart from getting me
up
> and running with xPL (finally got a couple of apps talking) I been
> bouncing around the idea of "platform indepedance" for
xplHAL(Manager).

Yep, this is something which is missing from the road map at the moment.

> Ian has explained that you've got xHCP in place which means that so
long
> as a platform has accessed to an xplHAL then we can regard the
"manager"
> (read GUI) piece independantly.

Yep, that's the idea.
XHCP is the protocol (TCP-based) that is used for the Manager and the
server
itself to talk to each other.
It's prooving to be a great architectural feature, and means we can easily
separate out the presentation/management from the core engine.

> John B is working on a perl implementation of xplHAL meaning all the
> Linux and MacOS bods out there will eventually have a script engine.
> However they'll still be lacking the lovely front-end afforded to
> Windows users in the form of xplHALManager.

This is true.
The Perl version does have a basic web server built-in, but it is only
intended
for initial setup and diagnostics - not for full management.

> There's a couple of ways this could be addressed - and I'm sounding
out
> some ideas from you guys.
>
> We could write a browser based front end to it (maybe using PHP,
though
> I'd prefer JSP) - giving us a very lightweight GUI, with no client
> install required - and remote access into the bargain. However, these
> are never as slick as stand-alone GUI apps.

This is the problem.
When xPLHal was first released (almost a year ago!) I wrote an ASP.NET web
front
end.
While this is a handy way of gaining remote access, development has
virtually
stopped on the grounds that it's so much better to use a full GUI,
especially as
we've pushed forward with the usability aspects (wizards etc.)

> For a standalone GUI app, I was considering writing an application
using
> Java (Swing). This would then be runnable on Windows, MacOS and Linux.
> It can also be "skinned" to make it look native to the
running OS or
> Window Manager. Granted it'll never be as nippy as true native app,
like
> HALManager, but it would be a write-once solution.
>
> Personally I quite like the latter idea - and in all honesty, I'm
> looking for a little Java project anyway - but I'm open to discussion.

This sounds like a good way forward, and would complete the missing piece
of the
xPLHal puzzle.

I therefore see 4 main components in the xPLHal collection:

- xPLHal server for Microsoft.NET: This is basically what we have now. It
is
optimised to make use of Windows/.NET-specific features and the VBScript
language.

- xPLHal server for Perl: This will run on any platform that has a Perl
implementation and will offer the same core functionality as the .NET
server.
The only piece missing is VBScript support, but we've decided to focus our
attention on determinators, as these are not tied to a specific technology
or
platform.

- xPLHal Manager for Windows: The present .NET manager - again optimised
for the
Windows environment.
- xPLHal Manager for Java: Intended to run on any platform that supports
Java.

In addition we could have any number of web-based front ends, written in
any
language.

I guess you could say: Why don't we drop the .NET versions and just go with
Perl
for the server and Java for the manager, but I think that as the .NET
products
are so far down the development path, it would be a shame to drop them
entirely,
especially as they offer features that may not be able to be reproduced in
the
cross-platform versions.

Just my thoughts.

Regards,

John