| | 1 | ideas/todo libasyncio |
| | 2 | ------------------------ |
| | 3 | |
| | 4 | smaller refactoring |
| | 5 | ----------- |
| | 6 | remove dependencies to libi2ncommon |
| | 7 | documentation, usage examples, website |
| | 8 | backend in separate file |
| | 9 | break backend::doOneStep in 4 functions |
| | 10 | separate pollfd, maybe encapsulate the pollfd-struct instead of deriving from it |
| | 11 | separate polldatacluster |
| | 12 | document that timerbase is always based on monotonic clock, getrealwhentime converts the time live |
| | 13 | document handling of error-cases, m_errno (e.g. mask ENOTSOCK for non-socket fds) |
| | 14 | provide simple replacements for system() and pipestream using simpleio and timeouts |
| | 15 | steal idea from pike-dvd-script: pipe-like program-chain |
| | 16 | |
| | 17 | bigger refactoring |
| | 18 | ------------------ |
| | 19 | put iolist, timerlist & child-handling into backend to reduce the usage of global objects |
| | 20 | make IOImplementations require a link to the backend they are used with |
| | 21 | |
| | 22 | ideas |
| | 23 | ----- |
| | 24 | offer a common io-client or io-server, abstracting out the real communication channel used. |
| | 25 | makes it possible to switch between ways of communication at runtime |
| | 26 | maybe filter-interface offers this functionality? |
| | 27 | |
| | 28 | boost::asio |
| | 29 | ----------- |
| | 30 | feature comparison to boost::asio |
| | 31 | interface/usage comparison, what is more easy to use for our usecase? |
| | 32 | long-term: merge with boost::asio, maybe with additional lib or keep it a separate project? |
| | 33 | |
| | 34 | glue_t2n |
| | 35 | -------- |
| | 36 | don't call doOneStep from within the fill_buffer()-variants |
| | 37 | - for the server-variants not that hard if you require that command_server::handle will be called on every socket-event |
| | 38 | - for the client: needs callback-interface on t2n-side, need to think about it |
git://developer.intra2net.com / libasyncio / blame_incremental