Re: [boost] [rfc] I/O Library Design

From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-19 17:49:15

----- Original Message ----- 
From: "Jeremy Maitin-Shepard" <jbms_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 20, 2007 8:33 AM
Subject: Re: [boost] [rfc] I/O Library Design

> Andrey Semashev <andysem_at_[hidden]> writes:
>
> [snip]
>
>>  From my point of view we have touched two problems in the discussion:
>> the ability to easy and efficiently format things into text or octet
>> strings and internationalization support.

With you so far, but there is so much more! ;-)

What if a developer wants to print an unsigned long as
an IP host address (dotted notation), within some debug
output? What if that same developer wants to allow for the
input of some IP address other than the printed default?

What if a developer wants to print a vector<site_security_profile> as
a readable table (headings, tabstops...), within some logging
system? What if the same developer wants to allow
for runtime input of the security profiles, beyond the content
of a file with appropriately formatted defaults?

What if a developer is initializing a UI report control with the
contents of map<SKU,shelf_item>? And the final product is
to be rolled out through a franchise spanning most of Europe?

Dont mean to be flippant with these examples. They are just supposed
to shine the light around; drag some significant parties into the
discussion, i.e. would resulting libraries be targeted at developers
and their debug requirements or developers and their pan-language
UI requirements?

A functional breakdown of the above might look like;

1. Character stream with embedded runtime values
* default format control on a per-C++ type basis
* format overrides (unsigned long as dotted IP)
* user-defined format for user-defined types
* user-defined input-text-to-type-instance conversion

2.Character stream with embedded runtime layout control
* default layout control for tabulation of STL containers (no headers, 8 
space tabstops)
* layout overrides (specific headers and tabstops)
* user-defined layouts for user-defined types (e.g. labels, 
line-per-type-member)
* navigation, selection and text input of layouts

3. Runtime construction of i8n display information
* too big to start listing

This is just a sequential listing; the order is not intended to be 
significant. The grouping
relates to the examples rather than a set of suggested proposals.

I suspect there is a matrix of end-user system requirements and potential
software technologies. Developers need to be able to declare at compile-time
whether the application debug stream has user-defined types and/or unicoding
requirements. Does the UI need to speak anything other than Cantonese (and
is that the developers first language?).

With that ability to "cook up" the different streams the potential arguments 
over
whether unicoding should be present within a debug stream evaporates. It 
becomes
a per-application decision.

As further input to this thread; I have recently done a lot of work in the
areas of serialization and also rendering that same information in different
UIs. There is an intriguing amount of overlap between what serialization
does and what debug/logging/UI streams need to do. While I wont go
as far as saying that application streams should exist over serialization
technology (hmmmm) there might be borrowed techniques?

Cheers.