How to create a complete custom store
This is a small introduction on what is necessary to create a full custom store from the implementation view. Naturally, this explanation is incomplete as this is a very complex task and highly depends on the physical store you want to interface Slide to.
Anyway, looking at your store this way you have to specify six interfaces - and an optional one - for a complete store definition. Additionally, you will need to implement an XAResource to let your store participate in a distributed transaction. This interface is specified by the JTA and is needed by Slide's internal transaction manager which also is more or less compliant to the JTA. Slide also requires the implementation of org.apache.slide.common.Service. I'd recommend to start from AbstractServiceBase as it sensibly implements many of the methods in Service interface.
Where to go from there highly depends on what you want to do. In any case you will have to implement all interfaces or supply implementation for all of them for a complete store definition. This means when you want to interface Slide to you proprietary store/CMS/whatever and you want all data to be stored there you will have to adapt all Slide stores to yours.
You may think I do not need security and I am not interested in Locking etc., but only in content, so I simply implement the ContentStore interface. This will not work, as you might not be interested in those features, but Slide needs them in any case. What you can do is implement the interface for content only and store the additional data to the file system or a relational databse. Note that in this case you will have half your data in your proprietary store and half of your data somewhere else. This is pretty ugly when you think of backups, recovery and the restoring of past states. Maybe this can make sense when your system uses a relational database and you combine it with the relational database store delivered with Slide, but I have never tried this.
Another possibility is to store the content natively to your system, but use the XML serialization feature also used by Slide's default store TxXMLFileDescriptorsStore. This way you will have two objects stored in your system, one for content and one for all descriptors set in NodeStore, LockStore, RevisionDescriptorsStore, RevisionDescriptorStore and SecurityStore. Recent versions allow you to reuse this feature. Have a look at XMLResourceDescriptor that inherits from AbstractXMLResourceDescriptor to store the XML into the transactional filesystem. Inherit from AbstractXMLResourceDescriptor yourself to store the data into your own system.
The Store Interfaces
The store described by this interface is responsible for storing and retrieving meta data for objects stored in Slide. While the actual methods are trivial the NodeRevisionDescriptor which is involved in almost all methods is the important one. It contains all properties and information on version numbers and labels. This NodeRevisionDescriptor is used by the ContentStore as well to specify the revision number and - where applicable - the content length.
This interface is the most important one. It is used to store the actual content of Slide objects. Besides the NodeRevisionDescriptor already mentioned its trivial methods use the important content objects. Such an object can hold text and binary content as streams or arrays.
As seen in other interfaces, the methods of this one are trivial as well. It is used to store all version information of a resource object including branch structure. All this information is stored in a NodeRevisionDescriptors object. References to actual versions are given using the NodeRevisionNumber. You can use it to get data from the RevisionDescriptorStore and the thus indirectly from ContentStore.
Here ObjectNodes are stored. An object node represents the structure of a resource object stored to Slide, i.e. it contains which object has which as parent and which as children. It also stores link and binding information.
A security store manages all permissions on resources. They are stored as NodePermission objects. Such an object tells us which user may perform which action on which resource. It thus maps to a WebDAV ACE entry and all NodePermission objects set on a resouce construct the ACL.
Locks are stored as NodeLock objects. A lock is set by a specific user on a specific resource for a specific action.
This is the optional interface that can be implemented. A SequenceStore can be used to generate a series of unique numbers. If you are not sure if you need this then you probably don't.
Implementing a reasonable XAResource
For all store implementations it is mandatory to implement the JTA interface XAResource. This is necessary to take part in transaction spanned by every WebDAV request done to Slide. If this is a good idea or not is not the subject of this small paragraph. Anyway, implementing a reasonable XAResource from scratch is a very troublesome and tedious thing to do, even if you have already implemented one before. I'd rather propose to use the AbstractXAResource from the commons transaction component. This has been done in recent versions of the database stores. The great transactional memory stores do this indirectly by using the transactional maps from the same component. Those maps use the the AbstractXAResource as well.