RE: [ros-general] More crazy ideas (was: Microsoft wants royaltie s for use of FAT)

[Colin Burn]

>  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.

[Andrew "Silver Blade" Greenwood]

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.



------------------------------------------------------------------------------


  _______________________________________________
  ros-general mailing list
  ros-general(a)reactos.com
  http://reactos.com/mailman/listinfo/ros-general

[Frank D. Engel, Jr.]

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.
>  
>  
>  
>  
------------------------------------------------------------------------------
>   
>  
>    _______________________________________________
>    ros-general mailing list
>    ros-general(a)reactos.com
>    http://reactos.com/mailman/listinfo/ros-general>
_______________________________________________
>   ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general 
=====
=======
Frank D. Engel, Jr.

Modify the equilibrium of the vertically-oriented particle decelerator to result in the
reestablishment of its resistance to counterproductive atmospheric penetration.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

[Andrew "Silver Blade" Greenwood]

Yes, someone did mention BeOS' method.

The way I was thinking of doing it, was to make it seamless - so the
applications see the files in the format it wants to see them in, without
requiring any modification.


----- Original Message ----- 
From: "Frank D. Engel, Jr." <fde101(a)yahoo.com>
To: <ros-general(a)reactos.com>
Sent: Friday, December 05, 2003 6:27 PM
Subject: Re: [ros-general] More crazy ideas (was: Microsoft wants
royaltiesfor use of FAT)


>   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.
> >
> >
> >
> >  
>  --------------------------------------------------------------------------
----
> >  
> >
> >    _______________________________________________
> >    ros-general mailing list
> >    ros-general(a)reactos.com
> >    http://reactos.com/mailman/listinfo/ros-general> 
> _______________________________________________
> >   ros-general mailing list
> >  ros-general(a)reactos.com
> >  http://reactos.com/mailman/listinfo/ros-general 
>  =====
>  =======
>  Frank D. Engel, Jr.
>
>  Modify the equilibrium of the vertically-oriented particle decelerator to 
result in
the reestablishment of its resistance to counterproductive
atmospheric penetration.
>  
>  __________________________________
>  Do you Yahoo!?
>  Protect your identity with Yahoo! Mail AddressGuard
>  http://antispam.yahoo.com/whatsnewfree
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general
>
>