[openxdas-devel] OpenXDAS 2.0 code base

[John C. <jca...@no...>]

David,

I've been thinking about what to do with openxdas relative to the future XDAS 2.0 specification.

As we've discussed in the past, XDAS 2.0 will probably NOT specify any API's. I believe this is a good move, but it makes it more difficult in some ways, and yet simpler in other ways to implement a library to the new spec.

It's simpler because there's much less standard to implement. That is, implementing the standard is simpler.

It's more difficult because the openxdas maintainer now has to do the work of coming up with a reasonable API, where "reasonable" is very subjective.

Regardless, I still think removing the API from the standard is the right approach. Focusing on the record format and taxonomy is much more important for a modern auditing standard.

Here are my thoughts on the OpenXDAS 2.0 code base:

1. Provide client libraries that are both statically and dynamically linkable.
2. Break the client library into at least two parts:
    A. A library that accepts audit data and returns a well-formatted XDAS record.
    B. An optional library that accepts an XDAS record, and submits to the OpenXDAS service.
3. Provide an optional auditing service.

OpenXDAS will then define "reasonable" C, C-Sharp and Java language bindings within the client libraries - both the record creation library and the submission library. Neither client library will depend on the other. 

The submission library will have to perform well-formedness checks on records before submitting them. While this increases overhead a bit on the client side, I believe the benefits of a split client library outweigh the increase in overhead. Furthermore, since the client-side will now be managing such checks, the back-end code for such checks can be removed (or at least reduced).

Users of OpenXDAS 2.0 will have the option of using just the formatter library, and submitting records in their own way - perhaps simply write them to a local file, the syslog system, or the Windows event manager.

Users will also have the option of submitting the record to the OpenXDAS service submission library, which will communicate with the more functional OpenXDAS back-end service. The back-end service will do the same thing it's always done: provide a pluggable logger framework, and submit all unfiltered events to each of the configured back-end loggers.

I believe the separation of client duties between two separate libraries - a formatter and a submitter - will make most people happy, and provide a set of code that is most usable by most people.

Comments?

Regards,
John