[wsf-c-dev] Issues for a next generation C stack

[James Clark]

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.

- 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