[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: libcodecs(3), take 4
> On Tue, Oct 05, 2010 at 01:45:46AM +0000, YAMAMOTO Takashi wrote:
>> >> 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?
Main Index |
Thread Index |