tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libcodecs(3), take 4



hi,

> On Tue, Oct 05, 2010 at 01:45:46AM +0000, YAMAMOTO Takashi wrote:
>> hi,
>> 
>> >> I hope this library becomes more modular.
>> > 
>> > You're going to have to help me out here - I have absolutely no idea
>> > what you mean.
>> 
>> i think you put too much into a single *.c file.
> 
> It is an easy way to force access through the library API itself,
> rather than just being able to call all functions.  If you know of a
> better way to do this, I'd love to hear it.

do you want "hidden" visibility?

>  
>> >> OTOH I'm not convinced that the add operation's "usefulness".
>> > 
>> > The "add" operation (codecs_add()) will add a transformation to the table.
>> > Is that what you mean?
>> > 
>> > Without it, there would be no transformations available. So still a bit
>> > unclear what you mean by this.
>> 
>> what's the point to export it?  ie. who is expected to use it besides
>> the library itself?
> 
> I think something's been lost somewhere along the way.
> 
> The codecs_add() function is used to add a function to the table of
> codecs.  This table is completely under the user's control.  If the
> user does not add any codecs themselves before invoking a
> transformation, then the default transformations are added to the
> table.  This is expected to be the default behavior.
> 
> The user can lockdown the table (in the sense that subsequent attempts
> to add a transformation will fail). It's not that difficult to work
> around, I admit, but the functionality is there.

given that the table is completely under the user's control already,
why he wants to lockdown it?

>  
>> talking about codecs_add:
>> 
>> - i don't think it's a good idea to use regex here.
>>   what will happen if someone does codecs_add(..., ".*", ...)?
> 
> Then every attempt to find a codec will match that codec.  The user
> controls what transformations are available.  The regular expression
> is the best way to govern this; I don't accept Uebayasi-san's
> assertion that regular expressions should not be used since they
> involve dynamic memory allocation - the memory involved in a regex_t
> is extremely small in today's terms, and takes place at regex
> compilation time.

if the user has the function to register with codecs_add,
why don't he simply call the function directly?

>  
>> - the "subset" concept sounds arbitrary and i don't understand how it could
>>   be useful.
> 
> Yes, this is to add the user in loading only the specific set of codecs
> that are needed. Say only the hash codecs are needed, then that's all
> that need to be loaded. It is a means of reducing the number of codecs
> to the bare minimum, and only allowing functionality which is absolutely
> essential to be available.

what's the point to not loading some codecs?

YAMAMOTO Takashi

> 
> Regards,
> Alistair


Home | Main Index | Thread Index | Old Index