conn: add more detailed documentation (WIP) #4652
Conversation
| * implementation keeps them compatible to each other. For example, an implementation might allow | ||
| * a UDP receive function to be called on a raw IPv6 connection object and even choose to do so | ||
| * for valid reasons (e.g. code size), but this definition does not impose this on the | ||
| * implementation. |
There was a problem hiding this comment.
I don't understand this explanation ^^. Can you elaborate?
There was a problem hiding this comment.
That's from the old documentation, I didn't write it ^^ I understood it as a warning that you can't rely on the implementations being completely interchangeable (for example, their definition of conn_udp may be different)?
There was a problem hiding this comment.
Ah yes. When I find the time I will propose a better explanation :-D
There was a problem hiding this comment.
If my interpretation was correct I can also propose one for you to judge ;)
There was a problem hiding this comment.
Note that there might be no relation between the different connection types.
For simplicity and modularity this API doesn't put any restriction of the actual
implementation of the type. For example, one implementation might choose
to have all connection types have a common base class or use the raw IPv6
connection type to send e.g. UDP packets, while others will keep them
completely seperate from each other.
|
@Lotterleben what is there still to do (since this PR is marked WIP)? |
|
There's probably a boatload of info missing that I just haven't learned yet, but yeah, It doesn't make sense to stall a PR for "maybe one day"s, does it? Do you have something important in mind that I should describe before we can declare this "good enough for now"? :D |
|
No, I would also declare it as "good enough for now". If there is more you can always add a new PR ;-). |
|
ACK & go, when Travis is happy |
|
Ah wait stop, please squash first :-) |
9b6c14c to
be72f2c
Compare
|
No worries, would've thought that was implied anyways ^^ |
conn: add more detailed documentation (WIP)
First attempt at trying to explain the relationship between conn, applications and network stacks a bit better. This is very much WIP and currently mainly exists for @authmillenon to shout at :)