| From: | David Trollope |
| Date: | 6 Sep 2000 at 04:27:05 |
| Subject: | Re: AMIOPEN: AmiPak |
Hi Jesse,
>> Just a side point here, but didn't Fleecy say that the new
> AmigaOS/DE/OE(?)
>> wouldn't have any files?
>
> Sort of.
>
>> Instead there is a system of services. Now I'm not sure how exactly you
> have
>> a system without files, but I'm sure we'll find out.
>
> 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? 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:
> I know I'm not giving you much, but that's the main idea behind it.
> Taken at a higher level of abstraction, all a filesystem is is a way to
> determine the difference between two files of the same name, and
> for the human user to apply some sort of meaningful (to them)
> conceptual ideas to one or more chunks of data. The user could
> care less *how* exactly those are handled, and thus the app
> programmer shouldn't have to care how those are handled, just
> that they are.
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?
> 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.
>> What I'm thinking is that AmiPak might become a service, i.e. a
> file-thingly
>> comes along and it asks for something to decode it, there are several
>> file processors around and AmiPak (which also handles .zip files I
>> believe) is picked, it decodes and so on.
>
> Something like that, yes. (:
> 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. Try defining an entry point for registered
tools like http or ftp deamons do, and have them invoked when a request for
a service arrives.
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....
Regards
Dave
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html