Re: Encodings.
Paul Schlie
(13 Feb 2004 02:18 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 03:35 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 05:59 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 06:36 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 08:00 UTC)
|
Re: Encodings.
Robby Findler
(13 Feb 2004 15:01 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 17:16 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 18:19 UTC)
|
Re: Encodings.
Robby Findler
(16 Feb 2004 01:03 UTC)
|
Re: Encodings.
Paul Schlie
(16 Feb 2004 03:21 UTC)
|
Re: Encodings.
Paul Schlie
(16 Feb 2004 04:18 UTC)
|
Re: Encodings.
Robby Findler
(16 Feb 2004 04:33 UTC)
|
Re: Encodings.
bear
(13 Feb 2004 17:40 UTC)
|
Re: Encodings.
Per Bothner
(13 Feb 2004 18:34 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 19:02 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 19:05 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 19:48 UTC)
|
Re: Encodings.
Per Bothner
(13 Feb 2004 19:11 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 19:44 UTC)
|
Re: Encodings.
bear
(13 Feb 2004 21:42 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 21:54 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 23:45 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 00:04 UTC)
|
Re: Encodings.
bear
(14 Feb 2004 01:06 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 01:08 UTC)
|
Re: Encodings.
Paul Schlie
(14 Feb 2004 02:35 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 03:00 UTC)
|
Re: Encodings.
Paul Schlie
(14 Feb 2004 03:04 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 03:08 UTC)
|
Re: Encodings.
Paul Schlie
(14 Feb 2004 03:29 UTC)
|
Re: Encodings.
Paul Schlie
(14 Feb 2004 02:19 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 03:04 UTC)
|
Re: Encodings.
Paul Schlie
(14 Feb 2004 03:10 UTC)
|
Re: Encodings.
Bradd W. Szonye
(14 Feb 2004 03:12 UTC)
|
Re: Encodings. Paul Schlie (13 Feb 2004 22:41 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 17:55 UTC)
|
Re: Encodings.
Paul Schlie
(13 Feb 2004 18:42 UTC)
|
Re: Encodings.
Bradd W. Szonye
(13 Feb 2004 18:53 UTC)
|
Re: Encodings.
Ken Dickey
(13 Feb 2004 21:53 UTC)
|
RESET [was Re: Encodings]
Ken Dickey
(14 Feb 2004 16:19 UTC)
|
Re: RESET [was Re: Encodings]
bear
(14 Feb 2004 18:02 UTC)
|
Re: RESET [was Re: Encodings]
Bradd W. Szonye
(14 Feb 2004 19:38 UTC)
|
I think I agree, under the presumption that for a root binary data port, there is a known correlation between data's external physical sequence and its internal representation (in other words, agree that the internal raw byte sequences accessible through ports, need not be literally stored internally a physical sequence of contiguous bytes of storage, but do suspect they would need to be minimally sequentially accessible as arbitrarily sized sequence of bytes stored as a sized bob (binary object), who's logical bit ordering is consistent with it's external physical storage representation. Where then these bobs (binary objects) which could then be operated on as an aggregate entity consisting of arbitrary collection of enumerated signed/unsigned integer fields who's values are extracted/inserted by specifying their bit position boundaries within the bob's binary field; That should be enough flexibility to get everyone in trouble. -paul- > From: bear <xxxxxx@sonic.net> > >> On Fri, 13 Feb 2004, Paul Schlie wrote: >> >> Agreed. >> >> But feel compelled to observe that once an object's internal representation >> is formatted/encoded to/from whatever external representations form is >> desired/required, it is then essentially in binary form; therefore binary >> I/O actually represents the root common port format for of all I/O; where >> more abstract ports may be thought of as merely munging on the data prior to >> sending (or after receiving) it trough a binary port; which although it may >> seem like a subtlety, if scheme were to view ports in this hierarchical way, >> it could form the basis of a very flexible data transformation and I/O >> architecture. > > Central idea: Right. If the binary port is primitive, then the > various kinds of character ports can be provided as libraries. > > I take issue with several of your "therefores" though; while I agree > with your conclusions, I don't think that the internal representation > of any kind of data is, or should be presumed to be, at all similar > to that which passes through a binary port. > > Bear >