Cosm API Review

Cosm has always been designed to be completely cross platform, and was started in 1995, which was 18 years ago. The computing world is far less diverse in 2013 and is dominated by flavors of Windows, Linux, and OSX, all with POSIX standards. Some of the CPU/OS and utility layer API’s now seem a little bit odd because they were for compatibility with systems that no longer exist in the wild. We also want to be sure we have APIs that are as simple and concise as they can possibly be.

Shared memory and named semaphores have been removed. They are generally useless for distributed systems (Cosm apps have never used them it turns out) and can fail in ways that are difficult to detect and recover from. Message passing has always been more flexible and much easier to reason about. So both have been removed to protect the innocent.

The defines OS_TYPE, CPU_TYPE, CPU_64BIT/CPU_32BIT, and COSM_ENDIAN are now fully auto-detected and set in cpuytypes.h. This simplifies the build system for those using Cosm. Doxygen documentation is also being added to replace the old HTML API docs as each function is reviewed.

The CosmFile and CosmDir functions in the CPU/OS layer will only deal with the local file system, and we no longer need to support VMS and MacOS (pre-X). The Cosm File System deals with all distributed files access. Since local file paths never leave the machine, the prefixing logic is no longer needed, which simplified the API. A function to locate the standard documents, configuration, and temporary storage directories at run time is being added.

Some things worked out far ahead of their need. Cosm has been based on UTF-8 and had IPv6 support since long before there was anything IPv6 to talk to. IPv6 still has a huge number of gotchas at the OS and routing levels, so we’re still waiting for it to be safely useable.

Quick note on cryptography – we’ll be moving fully to AES-256, SHA-3, and elliptic curves, all with a 256-bit length. We’ll be dropping support for the older crypto protocols entirely where possible, knowing the current protocols will likely be considered obsolete and weak in 10 years and need another update.

Much of the above is already completed, but more will be released to the code repository in the next few weeks. Simpler and easier APIs ahead.

Leave a Reply