###
### Ongoing stuff
###
+/* FIXME: better place? */
+int vasprintf (char **ptr, const char *fmt, va_list ap);
+char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
+Module renamings:
+ - rename SWAG to RING?
+ - Rename cursor to iterator
+
+log.h still contains @name which break doxygen:
+xbt/log.h:/** \name DEBUG
+xbt/log.h:/** \name VERB
+xbt/log.h:/** \name INFO
+xbt/log.h:/** \name WARN
+xbt/log.h:/** \name ERROR
+xbt/log.h:/** \name CRITICAL
+
+gras_socket_close should be blocking until all the data sent have been
+received by the other side (implemented with an ACK mechanism).
###
### Planned
The first ones should be repported to the user, the second should kill
the program (or, yet better, only the msg handler)
* Allows the use of an error handler depending on the current module (ie,
- the same philosophy than log4c using GSL's error functions)
+ the same philosophy as log4c using GSL's error functions)
[logs]
* Hijack message from a given category to another for a while (to mask
[modules]
* better formalisation of what modules are (amok deeply needs it)
- configuration + init() + exit() + dependencies
+ configuration + init() + join() + exit() + leave() + dependencies
+ init and exit are run only once
+ join and leave are run for each process.
* allow to load them at runtime
check in erlang how they upgrade them without downtime
* we may need a round-robin database module, and a statistical one
* a hook module *may* help cleaning up some parts. Not sure yet.
* Some of the datacontainer modules seem to overlap. Kill some of them?
+ - replace fifo with dynars
+ - replace set with SWAG
*
* GRAS
******
[doc]
- * add the token ring as official example
* implement the P2P protocols that macedon does. They constitute great
examples, too
* gras_datadesc_import_nws?
[Messaging]
- * A proper RPC mecanism
- - gras_rpctype_declare_v (name,ver, payload_request, payload_answer)
- (or gras_msgtype_declare_rpc_v).
- - Attaching a cb works the same way.
- - gras_msg_rpc(peer, &request, &answer)
- - On the wire, a byte indicate the message type:
- - 0: one-way message (what we have for now)
- - 1: method call (answer expected; sessionID attached)
- - 2: successful return (usual datatype attached, with sessionID)
- - 3: error return (payload = exception)
- - other message types are possible (forwarding request, group
- communication)
+ * Other message types than oneway & RPC are possible:
+ - forwarding request, group communication
* Message priority
* Message forwarding
* Group communication