The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: xPLHubs (again!)


  • Subject: Re: xPLHubs (again!)
  • From: "Mal Lansell" <mlansell@xxxxxxxxxxxxxx>
  • Date: Tue, 15 Mar 2005 00:12:17 -0000



In general I'd agree with your points, but in this particular case,
I don't think that cross platform issues figure at all.

The file is not transferred between machines - it is used only by
applications running on that computer.  Byte ordering is irrelevant
because a file written on a Mac (for example) would only be read
back on that same Mac, and not by another PC.

The same goes for file location - hubs compiled for Linux can
specify their own location, suited to that operating system.

I would normally agree with 2), allowing the format to be extended,
but if we were to do that, it could only be due to changing the hub
behaviour (because the format already contains all we need to run
the existing hubs).  A change to the hubs would require all
libraries with hub code to be updated anyway, and the format could
be changed at that point.

Mal




--- In ukha_xpl@xxxxxxx, Gerry Duprey <gerry@c...> wrote:
> Howdy,
>
> Speaking as someone who tries to create platform independent apps,
I'd like
> to suggest a few things:
>
>  > Seriously though, if it proves to be a problem, why don't we
use a
>  > binary format file instead - it'd be even easier to read/write.
>
> 1) Please do not do binary.  Different platforms handle binary
high/low byte
> encoding of 16, 32 and 64 bit numbers differently.  There becomes
no
> portable way to parse that number.  Text can readily be parsed.
While I
> tend to prefer XML (it's easy to embed XML parsers into most apps
to do the
> dirty work), a CSV format would be OK.
>
> 2) If a CSV format is done, lets agree that any additional/future
fields, if
> any, that are ever added are added only to the end of the line.
No
> inserting new fields between existing ones or re-ordering fields.
Again,
> this is for compatibility.  XML would provide a much more robust
method for
> handle future expansion (if any) of the file format, but if
everyone can
> agree to only append new fields, CSV should be more than practical.
>
> 3) If using CSV, line terminators need to be standardized.
Windows uses
> CR/LF, Unix uses LF only and Mac (last I checked) used CR only.  I
think it
> would be fine to use the Windows CR/LF as long as it's documented
so people
> writing parsers know what to do.
>
> 4) File name/location.  If this concept is valuable for windows,
it would be
> valuable for other platforms too.  So there should be some common
means for
> finding the file -- either written to a common path or specified
as a
> startup parameter to the hub (or read an environment variable if
nothing
> specified).  The Windows System/System32 directory would only be
of value
> for windows only apps.
>
> Just some suggestions to help broaden the appeal of xPL,
>
> Gerry
>
> --
> Gerry Duprey
> Ann Arbor, MI 48103
> http://www.cdp1802.org





xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx

xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.