<commit_before>Just some thoughts...

Q. How many SSLFacade objects per SSL transport
A. One object per transport

Q. What should the parameters of a wrap call be?
A. It can take any amount of plain data to be wrapped


Q. What should the return value of wrap call be?
A. It should return one or more TLS packets which are ready for transport.
Partial packets are not useful and not return from the underlying api anyway.


Q. What should the parameters of the unwrap call be?
A. It should take any amount of cipher data to unwrap.

Q. What should the return value of the unwrap call be?
A. It should return plain data for all complete TLS packets and store previously unconsumed partial packets for further consumption later. The host application does not need to worry about how much data was not consumed.

Q. Should the facade give a sync or async api for wrap ?
A. The biggest issue with giving a sync api is that a TLS packet cannot be transported till all of the plaintext payload is wrapped,this may not be ideal for performance in some server environments. Because we seek not to define or limit IO/Compute patterns for the host application it is better to chose an async api

Q. Should the facade give a sync or async api for unwrap?
A. A sync api for unwrap would force the host application to deal with the complexities that arise when the incoming bytes may have only partial TLS packets. These partial packets will not generate any plaintext from the SSLEngine till they are resubmitted completely to the SSLEngine. The resubmission is required because the SSLEngine does not keep any state of partial TLS packets. An async api would allow the host application to submit any length of bytes and whenever the facade is able to generate plaintext it will return via an async api. Additionally, the TLS packet demarcation will
usually not be visible to the host application.


Q. Should the async api of wrap take a callback each time or use one time set callback/listener?

A. A separate callback for each wrap call is useful if the requestor wants to to know only about a specific wrap request not all wrap requests.  This is not a likely consumption pattern here and so a callback is not ideal.


Q. Should this library be thread-safe?
A. No, this library shouldn't be thread aware as it may be used in
non-threaded environments. All thread safety is the responsibility of the
host application.


Q. How will you manage unconsumed input from an unwrap?
A. The remaining unconsumed input will be stored seprately and appended
before the next unwrap call. Care must be taken to ensure that no
buffer overflow scenarios occur.

* SSL/TLS packet size is fixed at 16KB by TLS RFC and<commit_msg>reformat developer.txt<commit_after>Just some thoughts...

Q. How many SSLFacade objects per SSL transport
A. One object per transport

Q. What should the parameters of a wrap call be?
A. It can take any amount of plain data to be wrapped


Q. What should the return value of wrap call be?
A. It should return one or more TLS packets which are ready for transport.
Partial packets are not useful and not return from the underlying api anyway.


Q. What should the parameters of the unwrap call be?
A. It should take any amount of cipher data to unwrap.

Q. What should the return value of the unwrap call be?
A. It should return plain data for all complete TLS packets and store previously unconsumed partial packets for further consumption later. The host application does not need to worry about how much data was not consumed.

Q. Should the facade give a sync or async api for wrap ?
A. The biggest issue with giving a sync api is that a TLS packet cannot be transported till all of the plaintext payload is wrapped,this may not be ideal for performance in some server environments. Because we seek not to define or limit IO/Compute patterns for the host application it is better to chose an async api

Q. Should the facade give a sync or async api for unwrap?
A. A sync api for unwrap would force the host application to deal with the complexities that arise when the incoming bytes may have only partial TLS packets. These partial packets will not generate any plaintext from the SSLEngine till they are resubmitted completely to the SSLEngine. The resubmission is required because the SSLEngine does not keep any state of partial TLS packets. An async api would allow the host application to submit any length of bytes and whenever the facade is able to generate plaintext it will return via an async api. Additionally, the TLS packet demarcation will
usually not be visible to the host application.


Q. Should the async api of wrap take a callback each time or use one time set callback/listener?
A. A separate callback for each wrap call is useful if the requestor wants to to know only about a specific wrap request not all wrap requests.  This is not a likely consumption pattern here and so a callback is not ideal.


Q. Should this library be thread-safe?
A. No, this library shouldn't be thread aware as it may be used in
non-threaded environments. All thread safety is the responsibility of the
host application.


Q. How will you manage unconsumed input from an unwrap?
A. The remaining unconsumed input will be stored seprately and appended
before the next unwrap call. Care must be taken to ensure that no
buffer overflow scenarios occur.

* SSL/TLS packet size is fixed at 16KB by TLS RFC and
{'fraction_non_alphanumeric': 0.02307976366322009, 'fraction_numerical': 0.0007385524372230429, 'mean_word_length': 4.043761638733706, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3807498', 'n_tokens_mistral': 1296, 'n_tokens_neox': 1253, 'n_words': 946}