Please take a look at their typical api's for data interface & storage,
you may change your mind.

> From: "Bradd W. Szonye" <xxxxxx@szonye.com>
> Date: Fri, 13 Feb 2004 19:00:08 -0800
> To: srfi-52@srfi.schemers.org
> Subject: Re: Encodings.
> Resent-From: srfi-52@srfi.schemers.org
> Resent-Date: Sat, 14 Feb 2004 04:00:17 +0100 (NFT)
>
> Paul Schlie wrote:
>> Record based text common on some pda's cell phones, etc. aren't files
>> they're simple data base fields which are access through distinct
>> api's which have no relationship to conventional C file functions for
>> example.
>>
>> You'll like this (therefore), it's likely ideally necessary to define
>> a common convention by which scheme may call C and/or Java foreign
>> procedures ala a c-lambda function and implied related facilities for
>> example, through which formatted text, numerical, and/or binary
>> objects which may represent encoded images and/or icon values (in
>> whatever format they require) may be passed back and forth. (back to
>> srfi-50 I guess)
>
> Huh? I can't parse that. I think you're saying that you'd use some text
> layer on top of a foreign database function. If so: No, that's not the
> best way to do it. Indeed, you can use standard I/O functions like READ
> and DISPLAY on that kind of system. You just need a Scheme system that
> understand the native text format, and a program that understands the
> limits of the format. Cobol systems do this all the time.
>
> There are *much* easier ways, language-wise, than what you seem to be
> suggesting here. But you can't do it with a simple text layer over
> binary stream I/O. Despite the popularity of Unix, everything is *not* a
> byte stream! In some ways, the binary stream model is inferior; Unix
> programmers who work with block-oriented devices have known this for a
> long time.
>
> In short, the "text over binary" abstraction is not always appropriate,
> and your zeal for that model can't change that fact.
> --
> Bradd W. Szonye
> http://www.szonye.com/bradd
>