[Novalug] Diabetes Software chance

[Peter Larsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nino Pereira wrote:
> Well, of course you supply the source. GNU/linux comes with a fortran
> compiler too. I suggested fortran 'cause that's all I know. You could
> to C, whatever.

The source wouldn't live by itself. It depends on system libraries in
particular when it comes to interacting with video and screen GUIs. The
reason C programs are hard to port from one platform to another isn't
the language, but the different set of libraries. While there are
cross-platform libraries, they aren't very widely used; and installing
on a non linux platform would mean installing a plura of system
libraries, like QT.

This is what Java solves. No special libraries needed. It works out of
the box. Any platform.

>> The software on the computer compensates for this. It downloads the
>> data, binary I assume (I don't know) with timestamps and meter
>> configuration information, that shows what unit of measure has been used
>> and sometimes a few meter specific configuration information. 
> 
> That, to me, is the crucial piece of information that you need to get
> started. Everything else is a question of: what do you want out of
> it, what's convenient for you to work with, etc.

That's what I have: a promise from Abbott will they provide me
specification of that interface. The issue simply is how to compose a
sales-pitch to allow me to "publish" the information as open source.

>> While ASCII is a good suggestion, it has several short comings. But an
>> open format is a must.  I'm thinking XML for now, or some other easily
>> read format. One of the short comings of ASCII is the lack of character
>> set encoding. XML solves that.
> 
> Hmmm, for my own education: what's a 'character set encoding?'

Not the whole world speaks English. There's quite a lot of languages
with more letters than 26 in their alphabet. Character set encoding is,
easily put, how the computer understands letters. ASCII-7 was made way
back in the 50'ies before anyone thought computers needed to speak
"human". It was an efficient format for slow computers but very
inefficient when it comes to any other language. Even though ASCII-8
solved a little bit of the problem, asia and most non germanic language
types were still not served by computers.

You may have noticed commands like "locale" and LC environmental
variables on your linux shell. Well, welcome to the international world
of computing. Everyone wants their computer to talk in their own
language - and why not?

The problem with the data is, that even if you store your nummrical data
in ascii, different locations read decimal numbers differently; dates
differently - and it's just a mess. Speaking as someone who's not "from
around here" it used to be one of the major problems with software from
the US - it simply could not understand simple dates and names of people
in your country. Even today even getting a domain name in your own
language - if it's not english, is tough if possible. ASCII isn't up to
the task. It wasn't meant to be used by non-english speaking countries
anyway.

If you think of XML as just ASCII files, you're missing a big aspect of
XML. XML by nature is stored in UTF8 although you can override that.
This means that SOFTWARE reading the files can present the data in it's
right format to the end user. This makes the file truly transportable
between platforms; ASCII is not. Btw. Java too is UTF8 natively for all
strings.

> All I'd want is a file that I can read with an editor. 

Users, in particular non-technical users, don't care about editors. They
don't understand them, and they're insecure. A simple typo and your code
fails with weird errors.

However, you need to think about what functionality you want before you
start thinking about it's implementation. A key aspect to an open system
is the ability to work with dynamic data structures. So as the features
of the system increases, data elements can be added without invalidating
older data sets. It's also important to make the data easily read by
software. Both is what XML solves. A pure old fashion CSV file doesn't
have metadata. It cannot validate the file; it cannot automaticially
detect different versions of the data.

However, XML also have drawbacks. Since you read your meter at least 2
times a day, that's 720 entries a year. Keeping all of that in one
memory structure isn't a smart move. Adding other data-groups to it, it
becomes quite a list to read through to just show the last 1-2 weeks of
data. Granted, it's not millions and billions of records.

> This way I can
> diddle with it on any system, with a line editor (like nano, which I
>  like a little ) or a full-screen editor (like gedit, which I like
> a lot), or even a word processor (like OpenOffice, or for MS people,
> Word: I don't like either much, to be honest). If you can read XML
> files with an editor, it's the same for me as ascii.

That's simply because you haven't read XML from other than english
language systems. With a normal ASCII editor, UTF8 looks unreadable
(it's a two byte system for each character).

Using XML also allows easy access by other readers; using XSD the
metadata is described and other code can make interfaces to the data
with a click of a mouse.

>> However, since the data needs to be disected by the software, 
> 
> This you can do easily, I think, with any (fortran or other) program.
> You program it to search through files, to calculate averages, etc.,
> whatever you want. That's the beauty of programming: there's nothing
> that prevents you from making it as elaborate as you want.

The question here was, that other programs were already out there to
make the graphs. Of course we can code us out of any issue. I think the
suggestion was meant to not having to reinvent the wheel yet another time.

> In programming I'm a command-line person, but I know that you can
> also put in data and stuff through GUIs. But, I've never done anything
> with GUIs, so I don't know what's involved.

Graphs are GUI and graphs gives you 1000 times more information than a
table with numbers. But any target audience would need a GUI; command
line isn't easy for a lot of people to understand; while I prefer it
personally that's now how people work with computers.

>> I was > thinking a small database like feature was needed.
> I don't think so, but who knows.

Emphasis on small. But yes, reading data can be done without databases.
It's just more work as you grow with your data.

> Good luck getting it done. IMHO, the first and most crucial step
> is: find out what the bits and bytes in the serial interface mean,
> and how these can be captured. That's what is different on
> the different OSs. I'd google for 'data capture under linux': I know
> there is something for it, but I haven't used it.

Right now the issue isn't HOW to code it. It's getting the specs from
Abbott so I can start getting the data in the first place.

- --
  Peter Larsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGpDTUHbLDna3OFD0RAkliAJ4z1VYhtSGy9ZGdGvule6GHaSnQ3ACgjjg9
kGlmoN5jTiDq8kljNCDVKNk=
=vMiI
-----END PGP SIGNATURE-----