From 470575df87b9aa8486f792729c9368a2f8eeffd4 Mon Sep 17 00:00:00 2001 From: Reinhard Pfau Date: Tue, 21 Oct 2008 08:21:21 +0000 Subject: [PATCH] libasyncio: (reinhard) updated ideas.txt from libsimpleio. --- ideas.txt | 29 +++++++++++++---------------- 1 files changed, 13 insertions(+), 16 deletions(-) diff --git a/ideas.txt b/ideas.txt index d5a8258..80073c7 100644 --- a/ideas.txt +++ b/ideas.txt @@ -1,26 +1,16 @@ -ideas/todo libsimpleio +ideas/todo libasyncio ------------------------ name ----- -don't use namespace i2n but namespace according to new project name - -ideas: -libsimpleio -libastiop (LIBrary for ASynchronous Timer, I/O and Process) -libsimpleasio -libasiocontrol -libasiohandle -libasioflow -libasiomaster -libiocontrol -libasyncrap -libasyncwrap -libasyncio +rename from libsimpleio to libasyncio +don't use namespace i2n +use namespace asyncio smaller refactoring ----------- +remove dependencies to libi2ncommon backend in separate file break backend::doOneStep in 4 functions document reason for ptrlist: keeps iterators valid during loops which do inserts/deletes @@ -35,13 +25,20 @@ provide simple replacements for system() and pipestream using simpleio and timeo bigger refactoring ------------------ -put iolist & timerlist into backend to reduce the usage global objects +put iolist, timerlist & child-handling into backend to reduce the usage of global objects make IOImplementations require a link to the backend they are used with ideas ----- offer a common io-client or io-server, abstracting out the real communication channel used. makes it possible to switch between ways of communication at runtime +maybe filter-interface offers this functionality? + +boost::asio +----------- +feature comparison to boost::asio +interface/usage comparison, what is more easy to use for our usecase? +long-term: merge with boost::asio, maybe with additional lib or keep it a separate project? glue_t2n -------- -- 1.7.1