Changes between Initial Version and Version 1 of Ticket #2193, comment 26


Ignore:
Timestamp:
2014-04-14T23:47:26Z (11 years ago)
Author:
daira
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #2193, comment 26

    initial v1  
    1 Re-reading the above comments, I think I may have given a false impression that I don't approve of the overall technical direction that the `cryptography` and `pyOpenSSL` developers are taking. That's not the case; I absolutely appreciate the need for FFIs between memory-safe and non-memory-safe languages to reduce the amount of glue code required, and to allow most of the remaining glue code to be on the memory-safe side. `cffi` seems to be on the right track here, and it's clear from reading the code of pyOpenSSL 0.14 that it should be a great deal more maintainable and less error-prone. (I've long been a fan of Standard ML's [http://people.cs.uchicago.edu/~blume/papers/nlffi.pdf NLFFI] which takes a similar approach.) Also, the ability to use multiple backends from `cryptography` is useful and important.
     1Re-reading the above comments, I think I may have given a false impression that I don't approve of the overall technical direction that the `cryptography` and `pyOpenSSL` developers are taking. That's not the case; I absolutely appreciate the need for FFIs between memory-safe and non-memory-safe languages to reduce the amount of glue code required, and to allow most of the remaining glue code to be on the memory-safe side. `cffi` seems to be on the right track here, and it's clear from comparing the code of pyOpenSSL 0.13 and 0.14 that it should be a great deal more maintainable and less error-prone. (I've long been a fan of Standard ML's [http://people.cs.uchicago.edu/~blume/papers/nlffi.pdf NLFFI] which takes a similar approach.) Also, the ability to use multiple backends from `cryptography` is useful and important.