ObjectApi refactors the original API and will be used to implement the ListAPI.

NebuloObject, NebuloList, NebuloFile

Composite design pattern: NebuloObject is a component; NebuloList is a composite aggregating an ordered list of NebuloObject. NebuloFile is a standard posix file stored in the system.


-NebuloObject() (it's not possible to contruct a new abstract file)

+NebuloObject(NebuloAddress addr)

(a representation of a file that exists in the storage addressed by addr; should it be exposed, or should we construct either NebuloList or BinaryFile?)

+static NebuloObject fromAddress(NebuloAddress addr)

+NebuloAddress getAddress() +void delete()


?should NebuloList explicitly implement java.util.List? No, no need.

+NebuloList(byte[] nonce)

  • empty list
  • the address of the new object is (groupId, |nonce|, nonce, fileId)

+NebuloList(NebuloAddress addr)

(a list that exists in the storage space)

(if the NebuloObject with addr is in fact not a list, throws an exception)

(if there is no NebuloList with address addr, throws an exception)

+void add(ListIterator iterator, NebuloElement newElement) throws NebuloException puts newElement after element pointed by iterator

+void append(NebuloElement newElement) throws NebuloException puts newElement at the end of the list

+void shuffle(ListIterator pred, ListIterator succ) Reorders the list so that pred is before succ.

+int size() number of elements

-bool worldReadable If true, everyone can download the list; if false, only the owner can download it (replicators authenticate the owner)

-bool worldAppendable If true, everyone can append elements to the list;

-long worldAppendLimit Size in bytes of the maximum element that can be added to the list by non-owner


(something similar to java.nio.channels.FileChannel ; allows for arbitrary reads and writes)

+NebuloFile(byte[] nonce)

  • empty file
  • the address of the new object is (groupId, |nonce|, nonce, fileId)
  • assumes that NebuloStore handles the mapping to a correct replication agreement
  • should the app layer suggest groupId?
  • should the app layer suggest expected size of the file? (to handle file size heterogeneity better?)

+NebuloFile(NebuloAddress addr) (a file that exists in the storage space)

+byte[] read(int pos, int len) (reads at most len bytes starting from position pos; might also take ByteBuffer as a parameter)

+int write(byte[] buffer, int pos) (writes buffer starting from position pos)

+int size() (number of bytes in the file)

+void truncate(int newsize) truncates the file

+void sync() ?should this be separate from write?


Represents the context of a connection to the network (peerId, an address of a node from a DHT used to initialize the lookup) and the state (connected / not connected).

Is passed during initialization to the network module.

Currently NebuloConnection static info is read from config variables.

Last modified 5 years ago Last modified on 10/14/13 19:08:02

Attachments (2)

Download all attachments as: .zip