RE: Re-connecting

On Thu, 24 Feb 2005, [iso-8859-1] Frédéric DUBOIS wrote:

> Ok, but the red light doesn't go off for me; I think there is a strong
> temptation to start with unifying common fuctionnality which seems to be a
> parent of the concept of factoring, and end up with generalyzing to unify. I
> guess it all depends on how you achieve this unification.
> But I must be misunderstanding what you mean. I've been impressed by the
> work you've done in CF - so I'm inclined to trust regarding the 'what' and
> the 'how'.

What I want might end up conflicting with what I'm willing to implement. 
And of course, the process of implementing can change your perspective or 
lead in different directions.

>
>>> If an application generates or act on "data objects" ( images, sound,
>>> traffic data, whatever ), then you use this application to manipulate
> these
>>> objects. I think it makes sense to say that this application ( or one
> module
>>> of ) should support the managment of these data objects. In Winux you
> launch
>>> your file manager, go into some subdir, click on a file and the
> filemanager
>>> reads its config files to guess what app to launch on the file. I
> suggest to
>>> launch the app first, and then the app presents you the files it has in
> its
>>> repository. No other program can present best than this app metadata on
>>> these objects, or sort them according appropriate criteria, at a minimal
>>> cost.
>>
>> This idea would not go away I don't think. If I want to see my email, then
>
>> a specialized view is more useful than a generalized view which includes
>> all data objects. But consider composing an email, why should this data
>> object be treated any differently than any other composition?
>
> Sorry, you lost me here. I'll try to respond by elaborating my idea.
> In my point of view, if the email is just text you compose it in an editor.
> Then you launch your POP3 client to send this "text object" to that person
> and fill-in the subject line. Maybe as intermediate step you can fetch the
> email address from a database.
> If your email is using a more sophisticated format - say HTML with pictures
> - you still write the body of your message in your editor, then you define
> the layout and include your pictures in a second app that supports HTML
> WYSIWIG, and then pass the result to your POP3 client.
> Of course this means that each app of this daisy chain has to provide some
> mean for another app to browse it's "data object" repository.

What came to mind when I read you original description was for instance 
the way mail clients today will maintain a database, and the only way to 
access email is through the mail client. The system may know nothing 
about email other than email is stored in a file in a particular 
location. From my point of view email is just a textual document, with 
some extra information like the subject, the sender, ect. A composition 
does not become email until it aquires essential properties like 
recipient, which perhaps the system will prompt for once you give the 
command to send your composition as an email.

  >
>> Further,
>> when it comes to searching the system, why should the contents of an email
>
>> be treated differently then the contents of any other textual data
>> object?
>
> Does this happen?

Yes, Google works this way and must deal with billions of data objects. 
How nice would it be to simply type a word or a phase and instantly access 
what you were looking for? Maybe it is not practical, but I would like to 
investigate this possibility.

> I rarely search something in a whole (file-) system, in
> particular when I know that this thing I'm looking for is in an email I
> sent. To handle this, I would have the text editor to offer a
> text-search-in-file capability that the mailbox app could use.
> I'm a bit in trouble here. We talk about abstract "data objects" and a
> would-be system and no-one has defined neither. For me, as for the system,
> we are talking about a CF-like system enhanced to take advantage of a hard
> disk, so you one store many applications and many data into a single mass
> storage device. This means to me that a "data object" is basically a bunch
> of bytes in a block.

Basically just bits, the meaning of those bits may be defined by 
the system, or a protocol. If I designate a bit sequence as a jpeg, then I 
don't really have to go any further, only the decoder needs to know the 
meaning of those bits.

>> I can't speak for Terry, but XML I think is not a good example. The type
>> systems of functional languages I think are a better example. Values are
>> encoded efficiently, and types are sufficiently general to represent
>> arbitrary data.
>
> Could you please give me an example of such functionnal language so I can
> take a closer look at the concept?

OCaml is one I am familer with, and I only give it as an example, not 
something to emulate exactly. I think functional language of this type are 
an interesting study in language design. They start with a very simple 
model of computation, the lambda calculus, which can represent any 
computation. The lambda calulus has no concept of integers, lists, 
addition, subtraction, however all of these can be encoded as terms in the 
language. The encoding of integers as church numerals would be very 
inefficient in practice. The type systems of functional languages express 
the kinds of data, and the kinds of programs, the designers think are 
useful. And typed data can have an efficient representation, for 
example integer can be directly represented as a binary word. Another view 
of a type, is as description of the data, that is why I bring up this 
example in particular. Although it does not exactly correspond to the 
notion of a database I had in mind.

Mark