Sorry for the lack of updates...

I've been working on Naikai's design when I'm not in the office, and I've started to realize a few things. I wish I were more close-minded. Designing software without a lot of experience is really tough. Really, really tough. I do have a list of things that I've learned, however:

  • Software development is hard
  • Some people want segregated systems (libpng and libaudiofile aren't part of the same framework, for example)
  • Others prefer integrated systems (the Java runtime) where base functionality is coalesced
  • Segregated systems are more flexible than integrated systems, but have more duplication of functionality

The specific problem I'm having is... I have this audio library, Acoustique (see the link to the left?). It has a single job: to decode audio streams into raw PCM data. I have another library that can spit raw PCM data into the sound card. By themselves, these libraries aren't all that useful. Together (with a background thread, of course) you have a full audio system. Now, the problem here is... There is no suitably portable threading API for C or C++. I *could* build a base library similar to the NSPR that would handle threading in a portable manner. If I go that route, however, anybody that wants to use my high-level API is required to bring my base runtime along with it. I don't like that very much, personally. :) I think I have a solution though... I *will* make a base runtime... But I will have one option for static linking and one for dynamic linking... Therefore, the high-level sound API will be available for external use, but I can still use the base functionality within my entire integrated system. So it's all good. :)

Okay, done rambling now. I hope at least somebody understood that...