an object is "code and data" not "just data".

Some would love you to make this mistake because 
XML, for instance, does not contain code it does encapsulate data, 
it can be made self descriptive, but it cannot execute or describe 
itself, nor can it uphold any method of compliance. It relies on a 
library to read it. The library does not need to know about the 
format of the object, but the application designer does.. 
At the very least XML could support true objects (code+data), as it 
stands XML is used to store data in ways that are easily converted 
back into C structs.. Data stored in XML can be misinterpretted, 
and it can't maintain itself, therefore its not really an object 
format.. True objects are self-aware.. 

Data formats while they may look like pointers in a C struct, they 
are not objects.. I think the biggest problem with objects is that 
they are thought to be like a format style  for data.. Really an 
object is like a person or a animal, it can perceive itself, it can 
describe itself, it can store things away, retrieve things.. Whereas 
a data format is like a particular configuration or possible 
configurations for an object, it can't interpret itself, you must 
know a lot more about how its stored and what everything represents 
in the file, you also must treat it different based on whether it is 
a file or if it is a byte stream.. 

It's a design concept more than a way you store your data. 
I think the bigger problem is that MCF is "a new data format" 
instead of a new media object format, its a implementation concern, 
no data format that is non-self interpretting will ever be easily 
maintainable, period, prove me wrong if you think it will.. Can you 
find a data format that can store itself, retrieve itself, comrpess 
itself, stream itself, without having to be completely understood by 
the application designer and the library designer, and is cross-
platform compatible and is backward/forward compatible. If its 
all of these, its an object format not a data format.. 

The media object is executed by a library which is designed to 
facilitate objects with instructions that allow them to describe 
themselves and store things in themselves, and the library is 
designed to facilitate the commonly used functions needed by media 
formats such as MPEG audio/video.. The objects or applets can be 
passed around (methods intact) or can be stored as AVI, Quicktime, 
MCF formats. But eventually the media format with be encapsulated in 
the object with the data and methods to describe how to 
extract/decompress the formats for frames, movies, 
and how to verify the contents, etc.. 

How its different for a library that reads a data format, normally 
the library would read the data format and have tocheck the file 
format to determine if it is a AVI, Quicktime, MPEG, etc. The 
library for a media object reads the object in text-based or binary 
form, and places it in a limited execution environment where the 
library can interface with the object and ask it for data and ask it 
to store data.. With its included methods, the object can access  
(thus store/retrieve) data it was designed to access.. 

With a data format the library must have knowledge of the object to 
be able to read it. With an object, the library needs only to have 
the instructions that the object needs to execute the object's 
methods, the methods contain the code necessary to interpret the 
data in the object.   

The part where the object would be like a data format, is that 
the object would have to have a standard interface to be recognized 
as a movie or as a audio clip or as a image, 
thus it would have to have at least a certain set of common methods 
to be compliant with the media object it represents. The media 
object itself is the only one that needs to know exactly how it is 
stored in a file and how it is retrieved.. 

Its like the difference between puting a hard drive mechanism with 
the disk or in the motherboard. Hard drives are CPU's with Hard Disk 
mechanisms, without it, all software as we know it would fail 
misserably because it would have to know specifically how data is 
stored on the disk and how to time accesses to retrieve and store 
blocks on the hard drive.. Your operating systems would have to 
know the specifics of the particular disks geometry and the 
operating system when it crashes would have to park the heads.. 
Luckily all of this is handled in the drive and not in the operating 
system, so disks designers do not have to write special dirvers for 
their drives..  

The pseudocode for a media object (note this is not the media object 
but a media object, the objects can be different the method names 
only need to stay the same):

class Movie { 

   class Frame { 
    Data *pointer; // points to a frame in the data..     
 
    method getFrame() returns Image { 
    }  
   }

   Data *pointer; // points to actual data
   Frame frames[]; // array of frames..  

   method Movie (ImageArray imarr) returns self {
      // A movie constructor, constructs a movie from an array of 
images if 
      // provided..  Otherwise just produces a zero-length movie.. 
      
      // Special code here to associate data in the Movie->data 
      // to particular frame objects, increase size of array of 
frame 
      // objects.. 
   }
   method getFrame(int n) returns Image {
   }
   method getFrameArray (int from, int to) returns ImageArray {
     // returns an array of images from the movie 
     // this, for speed purposes might do the CRC checks on the 
     // data directly, and extract the images directly without 
     // calling this Movie object to access each frame which 
     // would take too much time.. 
   }
   method storeFrame(Image *im) returns Boolean { 
   }
   method isCorrect() returns Boolean { 
    // performs a CRC check on data format, either 
    // directly on the data, or by asking a frame to perform a CRC 
    // check on itself.. 
   }
}

==================

Now although this object looks like a piece of C code, its 
a representation of how an object might be arranged, the data is 
stored in or appended to the object as normal, but the code that 
interprets the object is in the object its not in the library that 
reads it.. 

If the file format is 
improper, the object will determine this. There may have to be a CRC 
check done on the object itself to determine if it is correct 
before executing, it could even be digitally signed, etc.. How the 
object is stored and executed should not affect the way it is used 
by other applications.. It is stored just like a file in some file 
format, but there is no library to determine its format nor is there 
a library that is customized to read objects of its particular 
format. Thus there is no need for file format dependent code, 
the file is smart about itself, it can handle itself long after 
its been replaced with other better object designs because it 
can still access and store things in itself because the code to 
store and retrieve is part of the object.. 

The way its done now, with file formats, your data is seperate 
 from your code, the code is in the library, the data is in the file, 
the file doesn't interpret itself, the library must know a lot 
about the data before the data can be used.. What I'm suggesting is 
that the library contain something like a Sub-OpCode set (like how 
programmable CPU's are designed) that the objects use to implement 
their methods, the library bootstraps the object, the object 
interprets itself and makes requests to the library for more memory 
or for access, its up to the library to determine what the media 
object gets access to (so that media objects can't be made into 
viruses).. The library also interfaces with the objects, perform 
method queries (to determine the kind of object it is and how at 
least information can be retrieved).. If in the case that the object 
does not have a recognizeble interface, the user should at least be 
able to tinker with the object through the library.. The object is 
smart enough to be able to make sense to the user by describing its 
methods in plain english (it would be like trying to access a mail 
server through port 25 in Telnet, it could be like a friendly 
conversation).. The library doesn't need to know anything about the 
data contained in the object or how its stored, the object handles 
it all for the library, for the application, and the user.. 


Can AVI and Quicktime and MCF be used with this media object, yes 
but not in a way you might think about it? These formats are simply 
data, the one knowing more about these formats would write special 
code to interpret these formats, then this code would be put into 
the media object, for each file format there would be a media 
object, but the media object is not recognizeable as a AVI, 
Quicktime or MCF, ther media object library would take the 
code that interprets these formats and couple them with the media 
formats, you could say the media object is what it eats, it eats a 
AVI, therefore it contains the methods needed to work with the AVI 
file specifically, then the media object only need be passed around,
but software specifically designed to read AVI files could ask the 
object to divulge its media format.. This would overtime become 
phased out, and the media formats would get replaced by media 
objects.


The media object in affect eats the AVI or Quicktime, and absorbs 
its identity appending methods to it that simply access frames from 
the movies and add frames, insert frames, serialize it for storage, 
arrange it so it cna be streamed, all without the application having 
to know its a quicktime. The media object can then be transferred 
 from domain to domain as the media object and not as a Quicktime.. 
The Quicktime can still be extracted, but within the media object 
its identity as a proprietary format is lost, it then becomes a self-
describing entity called a movie.. 

Hey if you can't beat them, eat them!! That should be the slogan for 
the new media object format..  

Humor aside, the only thing that seperates you from making a 
revolutionary new media format is how you arrange your thought 
about it, if you think of it as a data format it will fail I 
guarantee it!! 100% If you treat it like a data format it will fail 
100%.. If you fail to give each media file its own ability to become 
self-aware, this new media format will fail I guarantee it!!


Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf