web commit by hammy: First draft

1 files changed, 62 insertions, 0 deletions

diff --git a/community/gsoc/libchannel.mdwn b/community/gsoc/libchannel.mdwn
new file mode 100644
index 00000000..88fd9971
--- /dev/null
+++ b/community/gsoc/libchannel.mdwn
@@ -0,0 +1,62 @@
+[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+
+[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU_Free_Documentation_License|/fdl]]."]]"""]]
+
+# libchannel
+
+*libchannel* was accepted as a project for [[Google_Summer_of_Code|gsoc]] (or
+just GSoC) in 2007.  It was written by Carl Fredrik Hammar who was mentored by
+Richard Braun.
+
+
+## Outline
+
+*libchannel* was intended to be used to cleanly and efficiently
+implement *channel* translators that would correspond to character
+device files.  In other words, translators for input devices, sound,
+network and the like.
+
+There are many cases where one wishes to stack translators over one
+another.  Take networking as an example, you may wish to have a pseudo
+network device that balance traffic over two real devices.
+
+The problem with stacking translators this way is that it's
+inefficient, for every RPC to the balancer a RPC is made to each of
+the real devices.  Now a RPC isn't really *that* expensive, but in a
+more complex example with more layers the overhead of these RPC's makes
+such a stacking infeasible.
+
+However, by using *libchannel* a translator can provide a description
+of what it does (i.e. the code and data it uses), which a translator
+layered untop can fetch and use directly.  Now only strictly required
+RPC's needs to be sent.
+
+
+## Result
+
+By the end of GSoC 2007, *libchannel* had mostly reached the initial
+goals.  There some code missing, most notably the code for
+transferring channels via RPC, but similar code was already present in
+*libstore* and can be trivially adapted for *libchannel*.  It also
+needed more debugging.
+
+Despite these minor deficiencies, the project was considered a
+success, never the less.
+
+
+## Future directions
+
+However, while *libchannel* matched the original specifications.  It's
+believed that it's too inflexible to make use of in many specific
+cases and that a more general solution is desired.  While the
+discussion isn't over yet, it seems *libchannel* will become a support
+library to implement specialized channel libraries, e.g. *libaudio*
+and *libnetwork* or similar.
+
+So work on *libchannel* will continue, in one form or another.