From: Paul Guyot (pguyot_at_kallisys.net)
Date: Tue Oct 21 2003 - 03:14:18 PDT
Aux environs du 20/10/03 à 16:55 +0100, sous le titre "[NTLK] FAT
Support through APIs: Was Re: newtontalk Dig", Andy Collins prit sa
plus belle plume pour écrire les mots suivants:
>Does these mean that a standard Newt app couldn't use a CF card with FAT
>layout?
Right now, it cannot. The card has to be formatted to the Newton
Stores Collection format and each partition in this partition map
format is a Newton Store.
>If so, that would be a shame. Would it not be possible for ATA driver using
>FAT to store Newt Soups as files?
No.
As in, I'm not going to spend two years on this.
Let me explain.
First, I cannot divide a store in soup files. This is what Victor mentioned.
The system expects ATA Support to handle objects. The operations are:
start a transaction, create a new object, read an object, resize an
object, get an object's size, write an object, delete an object, end
a transaction and abort a transaction. The system doesn't tell ATA
Support about soups. An in fact, there are other things than soups on
a card. There are VBOs (which are outside soups and are garbage
collected), data on the store and meta-data (like the name of your
store and so on).
Second, this would add an unnecessary overhead.
>That way I could backup easily by
>dropping the CF card in my Laptop. I could also drop MP3s on to the card
>and use some other (TBA) app to add them to a Newt soup (that may also
>exist on the same card).
What I consider is offering the possibility to backup to a file. Like
you select the soups & packages you want to backup and they'll be
saved in a flat file on the FAT partition. It would achieve exactly
what you're looking for, without the slow-ness. Of course, you could
have a mix card with a FAT partition (or more) and a Newton store (or
more).
I also consider letting you read MP3s directly from the FAT
partition. The rationale is that Newton storage system is highly
inefficient for something like MP3 playback. A big binary like a
sound or something like this is divided in little chunks, and ATA
Support has to find all these chunks.
Finally, you could export & import data in NSOF format, the Desktop
Connection Library would let you then read this data. I don't think
I'll write an application to handle these, except the NSOF to XML
converter (which could then be used with Michael Vacik's Notes XSL to
make an HTML note out of the data).
All this will be way less work than doing a not too pathetic store
system over a file. I mean not too pathetic because writing a store
system that puts objects in RAM takes few days.
Paul
-- Changement de baignoire. NPDS/NewtonOS: http://newton.kallisys.net:8080/ Apache/FreeBSD: http://www.kallisys.com/ -- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries List FAQ/Etiquette/Terms: http://www.newtontalk.net/faq.html Official Newton FAQ: http://www.chuma.org/newton/faq/
This archive was generated by hypermail 2.1.5 : Tue Oct 21 2003 - 07:00:01 PDT