You might look into the way this was done in the BeOS.
The BeOS had a
"Translation Kit" which provided pluggable translators which were made
available to various programs as an operating system service. Programs
would need to be written to take advantage of this, of course, but
since it could be done as a shared library of some sort...
--- "Andrew \"Silver Blade\" Greenwood"
<lists(a)silverblade.co.uk>
wrote:
RE: [ros-general] More crazy ideas (was:
Microsoft wants royalties
for use of FAT)Personally, I'd prefer to see this as a sort of API,
which is what I think you're suggesting.
I don't think COM objects would be the best solution, as it's pretty
much a Windows-only thing. If a different model could be used that
was portable, then maybe the file format handlers would be portable,
too?
I'm just thinking of the rather large picture - this design could be
adopted by Linux too, for example.
However, due to the recent events regarding FAT file systems, I was
thinking that this could be integrated into some sort of new file
system, with some way to allow attribute tags (a bit like an XML
structure in a way) so it's extendible.
I haven't really thought about too many of the details, but the main
advantages would be applications could use the new file system as if
it were an old one, and see files in several formats (so a MP3
appears as an MP3, a WAV, an OGG, etc. but no conversion is done
until the alternative format is used.) This would be for both new and
old applications, so it'd be backwards-compatible.
----- Original Message -----
From: Colin Burn
To: 'ros-general(a)reactos.com'
Sent: Friday, December 05, 2003 4:17 PM
Subject: RE: [ros-general] More crazy ideas (was: Microsoft wants
royalties for use of FAT)
To take another example, WAV MP3 OGG etc... All
audio formats. All
could
have a common interface, so any program could read
from and write
to these
files seamlessly, and the handler would handle
the
compression/decompression.
I dont think this really needs to be an OS feature but it might be
nice if any applications that come with ReactOS offered sort of plug
in file formats. You could easily write say an MSPaint clone that
used COM objects to access image files. 3rd parties would then be
able to write their own COM object for their own proprietary format.
As good as this would be I dont think it needs integrating with the
kernel but it should maybe something to bear in mind when people
start to write applications to be shipped with ReactOS.