Hi, On Wed, Sep 16, 2009, Florian Philipp wrote: > Of course I can't force you to do the programming but removing > functionality which worked - more or less - out of the box with an older > release and not providing any working alternative except of a > do-it-yourself solution ... well ... just sounds wrong. I think part of the explanation is lack of knowledge about exactly in which ways people use BlueZ and how popular these use cases are. To be honest, I'm not sure I still understand exactly what kind of behavior or feature you're after. > Okay, so without some significant work, you could only support legacy > pairing for those old deamons and I suppose that's all those test apps > can, right? Exactly which old daemons are you talking about? I don't see how any old software that isn't aware of the current pairing/agent interface could be made to work "without some significant work". > a) Create and maintain the missing parts myself. If the functionality makes sense and the implementation follows the usual coding standards that we have I don't see why you would be stuck maintaining it yourself. Surely it should be possibe to merge the work with upstream. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
