| From: | Jesse McClusky |
| Date: | 6 Sep 2000 at 21:20:12 |
| Subject: | Re: AMIOPEN: Filesystems and data conversion (was: Amipak) |
> From: "David Trollope" <dave.trollope@worldnet.att.net>
>
> > 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.
> Wow this is new, not. PIPE:, SER:, OS:, TCP:, RAM:, PRT:
>
> The problem with this whole theory is that each implementation has to fit
> within the constraints of that problem. For example, on the classic
P_IPE:_
> was a device (to the app) like any other. Problem was you couldn't seek or
> cd. One can argue thats simply a bad implementation, but PIPE was written
> to solve a problem. It did, it just caused other problems. What will be in
the
> new scheme to prevent that? Similar can be said for TCP:
This is for temporary and persistent storage of data only.
It is *not* like the original DEVICE: on the Classic Amiga.
> 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.
> > 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 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?
That's the whole point of tools...
> 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.
- 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.
Detect:
- The tool starts calling the light-weight (<1k usually) "detect" tool
under each type/* directory. It does this by calling "type/detect".
- 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.
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. (:
Jesse
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html