View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003506 | GNUnet | peerstore | public | 2014-07-29 16:28 | 2018-06-07 00:25 |
Reporter | amatus | Assigned To | amatus | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
Summary | 0003506: The peerstore plugin API should be asynchronous to support a wide range of storage backends | ||||
Description | I propose the API be changed to: /** * Store a record in the peerstore. * Key is the combination of sub system and peer identity. * One key can store multiple values. * * @param cls closure (internal context for the plugin) * @param sub_system name of the GNUnet sub system responsible * @param peer peer identity * @param value value to be stored * @param size size of value to be stored * @param cont continuation called when record is stored * @param cont_cls continuation closure * @return #GNUNET_OK on success, else #GNUNET_SYSERR and cont is not called */ int (*store_record) (void *cls, const char *sub_system, const struct GNUNET_PeerIdentity *peer, const char *key, const void *value, size_t size, struct GNUNET_TIME_Absolute expiry, enum GNUNET_PEERSTORE_StoreOption options, GNUNET_PEERSTORE_Continuation cont, void *cont_cls); /** * Iterate over the records given an optional peer id * and/or key. * * @param cls closure (internal context for the plugin) * @param sub_system name of sub system * @param peer Peer identity (can be NULL) * @param key entry key string (can be NULL) * @param iter function to call asynchronously with the results, terminated by a NULL result * @param iter_cls closure for @a iter * @return #GNUNET_OK on success, #GNUNET_SYSERR on error and iter is not called */ int (*iterate_records) (void *cls, const char *sub_system, const struct GNUNET_PeerIdentity *peer, const char *key, GNUNET_PEERSTORE_Processor iter, void *iter_cls); /** * Delete expired records (expiry < now) * * @param cls closure (internal context for the plugin) * @param now time to use as reference * @param cont continuation called with the number of records expired * @param cont_cls continuation closure * @return #GNUNET_OK on success, #GNUNET_SYSERR on error and cont is not called */ int (*expire_records) (void *cls, struct GNUNET_TIME_Absolute now, GNUNET_PEERSTORE_Continuation cont, void *cont_cls); | ||||
Tags | No tags attached. | ||||
|
I'm not sure I agree with this. Virtually all of our plugin APIs for *stores are synchronous, as it is perfectly acceptable for those APIs to briefly block during a DB access (sqlite, mysql and postgres APIs all may do some disk IO and should thus be considered 'blocking'). Which kind of backend are you thinking about where it would make sense to do this asynchronously, especially given that the peerstore process is already async with respect to the main application? |
|
I hadn't noticed that with the other plugin APIs, this is the first plugin I've tried to write to use IndexedDB. The IndexedDB API is asynchronous and javascript cannot block waiting on an event. I could write a memcache layer in my plugins where all changes are done synchronously and then written out to IndexedDB asynchronously. |
|
Sure, as long as you make sure that the event order is preserved; we do have tests that commit a value and than immediately expect an iterator to see it. |
|
Oops, a memcache layer would have to cache *everything* since reads from IndexedDB are also asynchronous. The APIs will need to change to support IndexedDB. |
|
Resolved in rev 34564. |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-07-29 16:28 | amatus | New Issue | |
2014-07-29 16:28 | amatus | Status | new => assigned |
2014-07-29 16:28 | amatus | Assigned To | => amatus |
2014-07-30 21:00 | Christian Grothoff | Note Added: 0008538 | |
2014-07-30 21:00 | Christian Grothoff | Status | assigned => feedback |
2014-07-30 21:41 | amatus | Note Added: 0008540 | |
2014-07-30 21:41 | amatus | Status | feedback => assigned |
2014-08-06 11:39 | Christian Grothoff | Note Added: 0008543 | |
2014-08-06 13:52 | amatus | Note Added: 0008544 | |
2014-12-15 01:33 | amatus | Note Added: 0008689 | |
2014-12-15 01:33 | amatus | Status | assigned => resolved |
2014-12-15 01:33 | amatus | Resolution | open => fixed |
2015-03-21 00:34 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
2015-03-21 00:34 | Christian Grothoff | Target Version | => 0.11.0pre66 |
2018-06-07 00:25 | Christian Grothoff | Status | resolved => closed |