[wsf-c-dev] Issues for a next generation C stack
Damitha Kumarage
damitha at wso2.com
Wed Dec 6 21:10:19 PST 2006
James Clark wrote:
>In moving the C stack forward in the medium term, there are a number of
>important issues that we need to reach consensus on. These are mostly
>low-level things that will have a pervasive influence throughout the
>code.
>
>Here are the main ones I've been thinking about so far:
>
>- Use of C++. Can and should we make use of C++? If so, what
>restrictions do we need to impose?
>
>- Error handling. How do handle errors? Do we return error codes or do
>we have some sort of exception handling? There is also logging to think
>about.
>
>- Memory management. What is are model for managing memory? malloc/free
>as now? Apache-style pools? Something else?
>
>- Concurrency. Do we use threading or an event-driven style or a
>combination? What's the flow of control: what pushes and what pulls?
>
>- Libraries vs daemons. What functionality is provided through libraries
>and what functionality (if any) is provided through daemons?
>
>- API/ABI. What style of API do we provide? What sort of binary
>compatibility between releases do we provide? How is it packaged into
>shared libraries/DLLs?
>
>- Extensibility. What extensibility points should be provided? What
>kind of binary compatibility is provided for extensions?
>
>- XML. What's the best approach to handling XML?
>
>- UTF-16. Obviously we have to support UTF-8. What level of support for
>UTF-16 is appropriate?
>
>- External dependencies. Which external libraries should we take a
>dependency on and how dependent should we be on them? libxml2 and curl
>are two obvious candidates.
>
>
As I remeber we talked about writing our own parser embeded into axiom.
So that removes dependancy on libxml2. How about improving our
own transport instead of using curl which will save us from another
dependancy?
Damitha
>- Evolution vs revolution. How do we get from where we are today to
>where we want to be eventually? Do we gradually evolve the current
>code-base or do we start a new code-base? The technical viability of an
>evolutionary approach will obviously depend to some extent on the
>answers to the above questions.
>
>If there are any other topics that you think are important, please
>mention them. Over the next few weeks I will post introductory messages
>to launch discussion of each of these; you might want to wait for those
>messages rather than starting the discussion immediately.
>
>James
>
>
>_______________________________________________
>Wsf-c-dev mailing list
>Wsf-c-dev at wso2.org
>http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>
>
>
More information about the Wsf-c-dev
mailing list