RE: Using native libraries for application development
If possible, with things like Libdisk and dmedia, I think it would be cool to add GUI support for more external drives that have removable properties. I've always found the operating system's limited support of removable SCSI media to be really irritating. There were a lot of removable disks in the day and it be cool to support more stuff via custom icons and usability at the desktop level with eject and insertion supported correctly, without becoming confused. It would also be cool to have better floppy support than what's there as well! Given that a lot of these drives are either somewhat self documenting with the SCSI standard or you could probably read Linux source code to figure out the nuances of how to use a lot of these different drives perhaps that's how we could add support for things like SYQUEST, JAZ, PCMCIA ATA FLASH over SCSI, more optical standards?
Or perhaps the ability to add file system support for more recent versions of file systems like newer UDF support (I mean a more recent standard/implementation than irix has, that other modern OSes use on DVD-RAM media...I've had major interoperability issues), exFAT, and support for DVD-RAM FAT32 automation and GUI support and even DVD-+R/RAM packet writing would be cool!
It just seems to me, and maybe I don't have enough experience if anyone can correct me, that you have to follow a very strict formula and file system requirements to get the Dmedia subsystem to work nicely without having some sort of problem with a lot of removable media & floppy media for PC/Mac interaction.
So some skeleton source code with compilation info and icon examples would be really cool. it's still pretty easy to find SCSI hardware that can do removable optical media that is rewritable. The documentation on some of the specifics is a little scarce but at least if we understood the subsystems involved we could independently research the rest that's device specific.
I know that zip drive support could be better than it is, and of course ZIP did appear at 250 MB that I don't think is supported well.
I know the things I'm talking about are very complex. But sample code could at least start in where do we put information about the drive, how do we inform the operating system about the various statuses and modes, what hooks do we need to implement from the operating system when the drive has a status update or some form of media change, basically how does a simple drive implementation work? And the OS stubs available to link that information into.
I've just seen issues where, as an example, the media demon doesn't understand when media has been ejected and therefore when you insert it it just freaks out. Things of that nature you think would just work but I've had issues with. Obviously it was a simple implementation made to work with very specific drives, they kind of told you this. But there are other removable SCSI drives out there and it be nice to have a more robust base that actually has the chance of handling them.
I also have an external PCMCIA ATA flash adapter to SCSI implementation, most are limited to 2 GB per flash module, but a lot of them can use CF adapters so it makes them pretty usable. If you combine that with a FAT32 file system and suddenly you have a really easy way of getting files back-and-forth on flash media instead of on optical between a modern operating system and a SGI machine.
It would be really nice to see the graphical desktop handle those things with grace versus just freaking out. I assume that these libraries are involved in that plus a little more.
ALso while thngs like ZuluSCSI are great, from what I understand they don't actually work well as a removable live data exchange mechanism, like like how one might use a USB flash drive. They're not designed to be removed while everything is running so you can't just put the SD card in have the OS detect the insertion of the card read the file system and supported Wright files to it then say you're going to eject it and then just remove the card and slip it into a modern machine. From what I understand that make of usage is totally unsupported both in hardware and software. I kind of feel that we need to go towards that kind of thing versus total in place emulation that never undergoes removal. I guess the accepted answer is you're supposed to use a network on the machine to get data on and off. But outside of older SSH support and raw FTP there isn't much else available these days given the change of standards that tap since then. I would feel better putting my machines away with removable drives installed then I would relying on remote connection techniques over ethernet, outside of basic FTP of course.
If that gives you any ideas for small utility apps then that sounds like something I'd be interested in seeing.
|