| From: | David Trollope |
| Date: | 7 Sep 2000 at 04:00:36 |
| Subject: | Re: AMIOPEN: Filesystems and data conversion (was: Amipak) |
Hi Jesse,
>>> I can explain a *little* bit. Basically, the idea is that the user
> should
>>> not
>>> be the one worrying about what filesystem(s) they are currently using,
> or
>>> what limitations it/they has/have. They shouldn't have to worry about
>>> where they stored something. Neither should the app programmer have
>>> to worry about those things. The only people that should are the OE
>>> coders.
>>
>> Not like the volume names of a classic by any chance?
>
> Nope. Goes way beyond that. More like an N-to-N database.
The concept is precisely the same. The application doesn't know anything
about the implementation of the named volume. The drivers underneath the OS
provide the same interface. This is why assigns work. The concept in the
classic OS is precisely what you describe. There was once an lh filesystem
that allowed you to traverse the archive like a filesystem. The app knew
nothing of it. It is the same concept. The classic never built on it enough
- and thats where I agree with you.
>> Doesn't sound like anything new to me. Whether you call it a file or a
>> stream or whatever, its a bunch of data read/written from somewhere.
>> Thats all a file is. The question will be what can you do with this data?
>> Can
> you
>> rewind and replay?
>
> It's not really a streaming system, more of an object persistence manager.
> You say, "I want this object to persist after I'm done." Then, you can
> make changes to it, do all sorts of things, and when your tool quits, it's
> taken care of for you. When your tool comes back, it's back;
> automatically, if you want it to be. You can also say, "I'm done with
> this object" and it will be taken care of for you, same as if you'd quit.
A classic device could be written to do this. Its just a slightly different
perspective.
>>> Trust me, it does work how it's going to be implemented.
>>> And it will cut a huge (or at least nice) chunk of development
>>> time out for almost every piece of software written.
>>
>> I want to understand whats new.
>
> And I'm doing my best to explain it without overstepping my bounds.
I understand!
>> > I personally like to look at it more as "actions available for a type
>> > of data".
>> > That way there any program can "mix-and-match" at will, without having
>> > to know or care about the details.
>>>
>>
>> Debatable. Its not necesarily efficient to have a thousand and one
> services
>> simply waiting. Waste of memory.
>
> How can they waste memory when they're not loaded?
I was refering to tasks waiting for messages - therefore memory is used. Of
course, if you have virtual memory, these tasks needn't even take memory
because they can be paged out....
> That's the whole point of tools...
The problem with tools being as dynamic as they are, you don't know if you
have everything you need to do something until you get half way through, and
find you don't have the right tool for the 5th step. This is not efficient.
A registery is needed to ensure that tools have sufficient other tools to do
its job.
>> Datatypes had it right when the app handed out a file and said "who
>> recognises this" and let them deal with it. You can't get in a situation
>> where you say "Can someone decode this MPEG file?" because you have
>> immediately tied the data type recognition to the app or the data type to
>> the OS. Of course in an AmiVerse where a thousand services exist you
>> can't wait for everyone to say, nope....
>
> Keep in mind that this may or may not be the opinion of Amiga, Inc:
>
> Here's my take on how it *should* be done. I'll use a directory
> hierarchy, because that's what people here are used to, and I
> don't want to confuse the issue. But trust me -- it's a *lot* more
> flexible without one.
I agree it just has to be a naming convention by which you know how to get
to something. Unix is /../../../.. the 3rd ... can be a virtual filesystem,
Classic is name:
> - A program encounters a chunk or stream of data, say, an MPEG2.
> - It asks (calls a tool, probably "type/convert") if it can be converted
> to an ANIM.
First problem - you have to be able to define ANIM. Is there a built in set
of known types or are you putting "ANIM" out there?
> Detect:
> - The tool starts calling the light-weight (<1k usually) "detect" tool
> under each type/* directory. It does this by calling "type/detect".
Do you mean there is a tool called type/detect, and that tool examines the
other dirs for tools? If so then you have implemented a slow datatype system
because it has to search the dirs for each request. You can have a registery
of tools, which is exactly how the datatype system worked.
You opened the object manager (the datatype library), and called
NewDTObject, equivalent to your type/detect. If the datatype library
couldn't find a datatype registered it returns failure. If a datatype is
found, the filename (could be a virtual device) is passed to the datatype,
and the datatype processes. You can then enquire from the datatype
attributes of the object through GetDTAttrs. Then when done with it you call
DisposeDTObject. Each of these classic library functions could be tools, but
you have to remember that the library itself was dynamically loaded in the
same way as a tool is. Its just they are loaded as one unit. Not really so
different. Add to that the device the datatype read from is abstracted so
the datatype doesn't know where its data is coming from, it could be the
net, it could be a file from disk. You can ask a datatype to save a data
block in its format too (assuming the datatype implemented that method) and
that corresponds to your persistance issue.
What you describe can be found on the classic in datatypes, devices
and libraries. Its just packaged differently.
> - Each detect tool returns a percentage, representing the likelihood
> of that data being one of its sub-types, as best it can tell.
> - Starting with the highest percentage returned, the detect tools under
> each sub-directory of the main MIME type are called, each of which
> returns a percentage.
> - If any of these percentages are over the threshold given by the
> original caller, then the *highest* one over that threshold is used.
> - type/detect returns the tool that gave the highest result over the
> threshold, or NULL if none were.
The threshhold is a neat idea, but how do you ensure the percentage
reflects the users desires? Author A might decide to return 50% for its tool
while another author decides to return 70%, yet the first tool will do the
better job. What would the guidelines be for determining a percentage?
> Convert:
> - Any tool in the type's directory starting with "2" converts to the
> given
> type.
> - If the type it converts to exists under a different primary type, then
> the format of the conversion filename is "2different-primary_sub-type".
> - If the target type is within the same primary, but no tool exists to
> convert it, or if the target type is within another primary type and
> no tool exists to convert it, then:
> - It is converted to a "general" type for its own primary type.
> - If the "2primary" tool does not exist when it is needed, the call
> fails.
> - The "type/primary/2new-primary_new-sub-type" conversion tool
> is called, if it exists.
> - If it does not exist, the "type/primary/2new-primary" conversion
> tool is called, if it exists. If it does not exist, the call fails.
> - The "type/new-primary/requested-type/2" tool is called, which
> converts from the new-primary's general type to the requested type.
> If it does not exist, the call fails.
> - If the target type is within the same primary type and no "2target"
> tool exists to convert it, then:
> - It is converted to the "general" type for the primary.
> - If the "2primary" tool does not exist when it is needed the call
> fails.
> - The "2" tool under the target sub-type is called, if it exists
> (fail if it doesn't).
> - If the target type conversion tool does exist, then use it.
>
>
> Keep in mind that this is just my personal vision, and does not
> necessarily reflect the views of Amiga, Inc. I see it handling
> both blocks of data as well as streams on-the-fly. I also see
> it automatically checking for "t" if "x-t" was specified, and other
> common-sense things like that.
>
> Sorry to get so long-winded. I tried to keep it short. Really. (:
Thats OK! I do understand where you are coming from. Perhaps we should take
this offline, unless others have something to contribute? Mail me directly.
Dave
>
>
> Jesse
>
> Subscribe/Unsubscribe: open-request@amiga.com
> Amiga FAQ: http://www.amiga.com/faq.html
Regards
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html