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)

-paul-

> From: "Bradd W. Szonye" <xxxxxx@szonye.com>
> Date: Fri, 13 Feb 2004 17:08:10 -0800
> To: xxxxxx@srfi.schemers.org
> Subject: Re: Encodings.
> Resent-From: xxxxxx@srfi.schemers.org
> Resent-Date: Sat, 14 Feb 2004 02:08:20 +0100 (NFT)
>
>> On Fri, 13 Feb 2004, Bradd W. Szonye wrote:
>>> Yes, you get out what you put in. However, when a system provides no
>>> "binary mode" or "stream mode" for text files, there is no way to
>>> implement a text port in terms of a binary port.
>
> On Fri, Feb 13, 2004 at 05:06:09PM -0800, bear wrote:
>> This is popping up a lot now in wireless devices; lots of them have
>> record-based text and stream-based audio for example.  As a 'small'
>> language scheme is a good candidate for embedded systems given a good
>> compiler; so it's probably not time just yet to abandon the idea of
>> record-based text as something that ought to be buried with the
>> dinosaurs.
>
> I wondered if there was anything like this in embedded devices, or if
> the only "niche" for record-based text was in the big iron machines.
> Good to know that I'm not just playing the "be friendly to dinosaurs"
> advocate.
> --
> Bradd W. Szonye
> http://www.szonye.com/bradd
>