Re: to be effcient or not to be efficient

----- Original Message -----
From: Attila Kinali <[email protected]>
Date: Wed, 7 Jan 2004 18:11:01 +0100
To: "The attempt to create a new,  open standard codec API" <[email protected]>
Subject: Re: [Media-api] to be effcient or not to be efficient

> On Wed, 07 Jan 2004 14:03:32 +0100
> Steve Lhomme <[email protected]> wrote:
> 
> > 
> > Consider this :
> > struct _blah {
> > 	uint16 Size;
> > 	uint8  FieldA;
> > 	uint32 FieldB;
> > 	char   FieldC[30];
> > };
> > 
> > Now (after a few years) you realise that you need FieldA to be on 2 
> > octets instead of 1. You simply can't. And you can with EBML.
> 
> Yes, but you can foretell whether there could be a need to extend
> a field as you already know what kind of information is available.
> Beside, i would consider a new version of the API if such a change
> is needed.
> 

Yup, new version of the API 1.0.0.1, now with 1 additional message/struct!

const int BLAH2 = whatever;

struct BLAH2_DATA {
uint16 Size;
uint16  FieldA;
uint32 FieldB;
char   FieldC[30];
};


Ok done. Now say we pass it to something that only supports the old blah message/struct? We get switch(whatever) which goes to default, pass through. Gets to the end of the chain, say the container. Nobody handles it? Return fail code to the caller, which chain reactions back to the app. What does the app do? Depends. Error message? Retry with old blah version? Who knows. Who cares? Not our problem. How to check if the components handle an API version? Have it reported to the app when the API load function loads the binary and does init. Then it's all on the app. Problem solved.

How do we indicate failure? I dunno, since everything needs to indicate failure, and on failure we're obviously not returning any valid data, how about we just pass 0 back as the message data struct's pointer? I know, null pointer == bad, but everyone who's going to use the data SHOULD be checking for failure anyway to prevent garbage in garbage out right? Then it should test first and never attempt to access the null pointer so we're safe. Not checking for failure would then be an obvious to spot bug as you'd get a null pointer access and thus should be able to catch instead of just wondering "Why the hell aren't I getting good frames on input?" If the app sees msg_data == 0; when a message comes back, it knows there was a failure. Likewise any component that's going to try multiple ways of doing something. It also saves the time of needing to decode any kind of data structure to check 
 for the error flag, it's obvious immediately and thus very fast to process.




-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm