Phil Dibowitz wrote:
> Stephen Warren wrote:
>> It'd be nice if all symbols (types, values, functions, etc.) were all
>> prefixed with e.g. "IRR_"/"irr_" to ensure they never conflict with any
>> other library.
> 
> ACK for the public functions, definitely.
> 
> I highly prefer lower case.

Yeah, I meant irr_ for functions, IRR_ for defines/enums.

>> Doesn't the LIRC project have a library that does this kind of thing
>> already, that could be re-used instead of re-inventing the wheel? In
>> fact, don't they have a big database of key codes that might be useful?
> 
> I was going to go do some research on if another library already did
> this, actually, but never got around to it. If another library already
> supports the actions we're looking for with a decent API, we shouldn't
> merge our own without good reason.

I took a look at LIRC. It doesn't seem like they have a separate
NEC/RC5/... protocol encode/decode library (although perhaps they have
that code just hidden inside lircd or something). I guess looking at the
Pronto format, it's also essentially just a list of mark/space timings,
so perhaps needing IR protocol encode/decode functionality isn't that
common right now, so a new library makes sense. Still, I didn't search
outside of the LIRC project yet, so that'd be worth doing too.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel

Reply via email to