View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003108 | GNUnet | util library | public | 2013-11-11 21:20 | 2018-06-07 00:25 |
| Reporter | tg | Assigned To | tg | ||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
| Summary | 0003108: Separate message handler functions for the client library | ||||
| Description | Currently the server and client library are inconsistent in the way they implement message handler callbacks. The server lib takes a handlers array with a separate callback function for each message type: void GNUNET_SERVER_add_handlers (struct GNUNET_SERVER_Handle *server, const struct GNUNET_SERVER_MessageHandler *handlers); And a function to resume receiving: void GNUNET_SERVER_receive_done (struct GNUNET_SERVER_Client *client, int success); While the client lib has a single receive function that takes a message handler callback that receives all messages: void GNUNET_CLIENT_receive (struct GNUNET_CLIENT_Connection *client, GNUNET_CLIENT_MessageHandler handler, void *handler_cls, struct GNUNET_TIME_Relative timeout); The server API is cleaner, changing the client API like that would make the client code a bit cleaner. This would take more time to fix as it affects every service. Perhaps it is more feasible to implement the new API and remove the old one after every service switched to it, this would allow new services already use separate message handlers. (Or alternatively a temp solution is to implement a function that can be passed in as a callback to GNUNET_CLIENT_receive() and takes a MessageHandlers array as argument) | ||||
| Tags | No tags attached. | ||||
|
|
Yes, this was already discussed between me and (IIRC) Florian Dold. I'm not against making the client API resemble the server API more in principle, but this is a somewhat invasive change and the existing code does work, so it hasn't been a priority for me. But in principle changes in this direction that do not break stuff are fine. |
|
|
I have implemented this in the client manager API. This way the old API did not change, and new services can use the higher level API if desired. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-11 21:20 | tg | New Issue | |
| 2013-11-13 21:56 | Christian Grothoff | Note Added: 0007628 | |
| 2013-11-13 21:56 | Christian Grothoff | Status | new => confirmed |
| 2014-06-02 18:01 | tg | Assigned To | => tg |
| 2014-06-02 18:01 | tg | Status | confirmed => assigned |
| 2014-06-02 18:01 | tg | Note Added: 0008378 | |
| 2014-06-02 18:01 | tg | Status | assigned => resolved |
| 2014-06-02 18:01 | tg | Fixed in Version | => Git master |
| 2014-06-02 18:01 | tg | Resolution | open => fixed |
| 2014-06-08 15:16 | Christian Grothoff | Fixed in Version | Git master => 0.11.0pre66 |
| 2014-06-08 15:16 | Christian Grothoff | Target Version | => 0.11.0pre66 |
| 2018-06-07 00:25 | Christian Grothoff | Status | resolved => closed |
