XIRUSS-T Update: Client Almost Done

I have achieved the milestone in my HTTP client implementation in that my client test case demonstrates that you can create new versions, commit them to a branch, and get them back again via the newly-created snapshot. This is the core functionality needed to get things into the repository and get them back. I also demonstrate support for all the methods on RepositoryObject (the base class for all objects managed by the repository). This code committed to the Sourceforge Subversion repository.

Still to do:

- Implement all the remaining methods on Version

- Implement writing to storage object versions via the API client helper

- Figure out the best model for getting a new repository and session on the client side (this is an API design question not a functionality question).

- Refactor the organization of the various interfaces and classes to clearly separate the stuff that is only relevant to servers from stuff needed by clients so that the client-side library can be as small as possible. This will also involve refactoring the abstraction layers from the core repository up through the Xiruss-specific HTTP server. There needs to be a clear abstract layer that adds in user and session awareness. I feel strongly that the core repository data model be completely generic so that it can be exposed as essentially a single-user process. Issues of multi-user support, including authentication and so forth are implementation issues that need to be able to vary among implementations. In addition, things like supporting multiple users or ensuring transaction safety and so forth are performance and scalability issues that I am explicitly not addressing in XIRUSS-T. These are things that could be addressed either on top of the base code using aspects or how the server-specific objects are implemented or at the core SnapCM object implementation level. But none of that is needed in order to provide a semantically correct distributed server and ignoring those issues here keeps the code very very simple, which is my goal.

I've been thinking about it and I realized that with XIRUSS-T I don't want to impress anyone with the dazzling complexity of my code but with the breathtaking simplicity of the underlying data model and the core implementation objects. My whole point is that these complex challenges of management of versioned XML compound documents can be met through the use of fundamentally tools used in clever ways.