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