ant elder wrote:
I'm not sure i agree about the sample, wont it be even more confusing having it use the old way? Maybe if there was something the sample was doing that required the complex SPI but while there isn't wont it just seem odd to do
it an unnecessarily complicated way.

Do we even want this simpler SPI? If we do i think we should use it, if we don't we should scrap it now, which I'm fine with doing. Maybe it would be
better to just move some of the simplifications to the existing SPI?

  ...ant


I'm still on the path that we were discussing earlier in [1], and I thought we were pursuing: - a simplified extension SPI layer, for simplified bindings and implementations that don't need the power of the complete/advanced SPI
- on top of the more advanced SPI, not replacing or altering it
- clearly identified in separate packages

I don't think that having 2 samples for the 2 separate SPI layers is confusing. We just released a 0.90 release with stable SPIs that we want people to use, we should continue to have a sample illustrating how to use these SPIs. If implementation-crud does not make good use of some of the interesting SPI methods (like some of the start/stop methods) we should just improve the sample and add a few print statements for example indicating what could be done in these methods...

And we can have a different sample showing how you can use the simplified extension SPI layer for a simpler implementation extension.

--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to