aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--misc/raa_format.txt71
-rw-r--r--src/cachehandler.cpp2
-rw-r--r--src/cachehandler.h18
-rw-r--r--src/cacheptr.cpp0
-rw-r--r--src/cacheptr.h0
-rw-r--r--src/nids.cpp21
-rw-r--r--src/nids.h49
-rw-r--r--src/nidsstream.cpp10
-rw-r--r--src/nidsstream.h18
9 files changed, 189 insertions, 0 deletions
diff --git a/misc/raa_format.txt b/misc/raa_format.txt
new file mode 100644
index 0000000..1b2c9f8
--- /dev/null
+++ b/misc/raa_format.txt
@@ -0,0 +1,71 @@
1Random Access Archive Format
2----------------------------
3
4This is the basic archive format for libbu++'s random access archive system.
5Unlike the traditional archive, given a unique key any object may be accessed
6at any time, and hopefully very quickly.
7
8To make this as portable as possible the basic interface to the RAA is very
9simple and seperated from any IO or formatting directly, any number af backends
10could be constructed quite simply, this is a description of the first of these
11formats.
12
13In order to make the system handle objects that are any size, and grow quickly
14and easily, I believe we should resort to a simple block allocation mechanism
15with uniform block sizes linked in chains, effectively accessed via "inodes."
16
17Therefore given a blocksize and a Table of Contents (TOC) any object should be
18easy to find. The TOC can be implemented as an in-place hash table to minimize
19the amount of memory that must be sacraficed for very large, seldom used
20structures.
21
22The basic header:
23
2400-03: Magic Number, something cute, I dunno yet (encoding independant)
2504: Byte count/order for standard indexes (8/4 for 64/32bit systems)
26 High order bit masked out determines endianness (1 = big, 0 = small)
27 The program will only accept one word-width for now, we can make it
28 adjustable later, or fix this at 4 bytes.
2905-08: Blocksize in bytes, could be anything, I don't think we need to worry
30 about OS related things for this, but it should be set intelligently by
31 the owner. This includes the bytes reserved for a block header.
3209-12: Total block count, includes both used and unused blocks.
3313-16: Total used blocks, useful for determining when to expand.
3417-24: Reserved for flags and the like, should be all zeros for now.
35
36At this point are a number of "blocks" each with their own header and data are
37laid out sequentially, accessing one should be easy, seek to
38 (header size)+(block size)*(block number)
39
40The block header is as follows:
41
4200-03: First block in chain. If this number matches the current block index
43 then this block is the first in a chain.
4404-07: Next block in chain. If this number matches the current block index
45 then this block is the last in the chain.
4608-11: Prev block in chain. If this number matches the current block index
47 then this block is the first in the chain.
4812-15: Number of bytes used/allocated remaining in the chain. If this is the
49 first block, then this is the total size of the object accross all
50 blocks in the chain. For the last block in the chain this will usually
51 be less than the available space.
5216-19: Reserved flagspace or something, make sure it's all zeros.
5320-xx: Block data, whatever you wanted to store. At the moment this is going
54 to be (blocksize) - 20 for now, it will change if the block header
55 changes.
56
57Thus far we have described a generic system for storing dynamic "substreams" of
58data within a larger stream using a block-allocation system. This is handy on
59it's own, and implemented as a seperate mechanism, but as handy as it is, it's
60not as useful without a table of contents, described here.
61
62Any above composite datastream that uses a TOC will have the TOC be the first
63block chain. The TOC will initially be a basic in-place hash table, but may
64be changed to a b-tree depending on what kind of data is being used. This basic
65table of contents simply links a generated UID from a program to the appropriate
66block chain.
67
68Systems like the above could be augmented with additional meta-data in order to
69create flexible, small, in-file file systems and the like. For example,
70providing simple fixed-width data structures to tie to "inodes" (the program
71generated UIDs) you could have a mini posix filesystem in no time.
diff --git a/src/cachehandler.cpp b/src/cachehandler.cpp
new file mode 100644
index 0000000..d208e98
--- /dev/null
+++ b/src/cachehandler.cpp
@@ -0,0 +1,2 @@
1#include "bu/cachehandler.h"
2
diff --git a/src/cachehandler.h b/src/cachehandler.h
new file mode 100644
index 0000000..8841b4e
--- /dev/null
+++ b/src/cachehandler.h
@@ -0,0 +1,18 @@
1#ifndef BU_CACHE_HANDLER_H
2#define BU_CACHE_HANDLER_H
3
4namespace Bu
5{
6 template<class obtype>
7 class CacheHandler
8 {
9 public:
10 CacheHandler();
11 virtual ~CacheHandler();
12
13 forceLoad()
14 private:
15 };
16};
17
18#endif
diff --git a/src/cacheptr.cpp b/src/cacheptr.cpp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/src/cacheptr.cpp
diff --git a/src/cacheptr.h b/src/cacheptr.h
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/src/cacheptr.h
diff --git a/src/nids.cpp b/src/nids.cpp
new file mode 100644
index 0000000..b8ea13b
--- /dev/null
+++ b/src/nids.cpp
@@ -0,0 +1,21 @@
1#include "bu/nids.h"
2
3Bu::Nids::Nids( Bu::Stream &sStore ) :
4 sStore( sStore )
5{
6}
7
8Bu::Nids::~Nids()
9{
10}
11
12void Bu::Nids::initialize( int iBlockSize, int iPreAllocate )
13{
14}
15
16int Bu::Nids::createStream( int iPreAllocate )
17{
18 return 0;
19}
20
21
diff --git a/src/nids.h b/src/nids.h
new file mode 100644
index 0000000..9954146
--- /dev/null
+++ b/src/nids.h
@@ -0,0 +1,49 @@
1#ifndef BU_NIDS_H
2#define BU_NIDS_H
3
4namespace Bu
5{
6 class Stream;
7
8 /**
9 * Numerically Indexed Data Streams. This is a working name so I can
10 * actually get some code written instead of agonizing over the name.
11 *
12 * This is a system for creating streams that contain other streams in
13 * a flexible block-allocated system.
14 */
15 class Nids
16 {
17 public:
18 Nids( Bu::Stream &sStore );
19 virtual ~Nids();
20
21 /**
22 * Create a new Nids system in the assosiated stream. This should be
23 * used carefully, it will destroy all data already within the stream.
24 * More options will probably be added soon.
25 */
26 void initialize( int iBlockSize, int iPreAllocate=1 );
27
28 /**
29 * Create a new stream within the Nids system. The ID of the new stream
30 * is returned.
31 */
32 int createStream( int iPreAllocate=1 );
33
34 /**
35 * Delete a stream that's already within the Nids.
36 */
37 void deleteStream( int iID );
38
39 /**
40 * Return a new Stream object assosiated with the given stream ID.
41 */
42 Bu::Stream &openStream( int iID );
43
44 private:
45 Bu::Stream &sStore;
46 };
47};
48
49#endif
diff --git a/src/nidsstream.cpp b/src/nidsstream.cpp
new file mode 100644
index 0000000..d05fbc0
--- /dev/null
+++ b/src/nidsstream.cpp
@@ -0,0 +1,10 @@
1#include "bu/nidsstream.h"
2
3Bu::NidsStream::NidsStream()
4{
5}
6
7Bu::NidsStream::~NidsStream()
8{
9}
10
diff --git a/src/nidsstream.h b/src/nidsstream.h
new file mode 100644
index 0000000..08b45eb
--- /dev/null
+++ b/src/nidsstream.h
@@ -0,0 +1,18 @@
1#ifndef BU_NIDS_STREAM_H
2#define BU_NIDS_STREAM_H
3
4#include "bu/stream.h"
5
6namespace Bu
7{
8 class NidsStream : public Bu::Stream
9 {
10 public:
11 NidsStream();
12 virtual ~NidsStream();
13
14 private:
15 };
16};
17
18#endif