#Interface design
6 messages in this thread
Using device drivers sounds like an interesting idea, but I think it would be
simpler to use plain message ports. I was also thinking of just one
File-requester task that would be used by every program on the system. This
presents some interesting synchronization problems if more than one program
tries to get into the File-Requester, however, there are some nice things you
could do as well. For example, the F-R task would be able to preserve the
disk/directory context while switching from program to program, so disk access
could be sped up a lot.
The other attractive thing about this approach, is that it would fairly easy to
use a multi-processing system, you know where tasks could be running on a
network of Amigas….
. Richie
The device interface would provide all these features quite easily I think. The
IO block used to communicate with the device could hold all necessary state
information. The device could easily maintain cached directories and share
these among the different requesters, etc… Aside from Intuition, the Amiga
does not currently have some standard tasks just hanging around with a msg port
reay to access. On the other hand, devices are quite common and well
understood.
Anyway, as long as there's something standard.
Martin, the Amiga can have such a task – ARexx!
And that's the way to do it, I think. In fact, I have. <grin>
I do agree that ARexx makes for a nice system. It's also easy (well if you're a
programmer) to replace any component by another one. I was thinking of ARexx's
speed, but I guess for these types of applications, IPC speed is not an issue.
Richie,
No problem with synchronization… simple reentrant coding and unique caller
ID numbers could keep that all straight.
-larry