Seco Server

#summary Describes Seco servers - HGDB backend to store Seco atom.

= Introduction =

A Seco server has the following purpose:

• Store Seco atoms for the purposes of back up and fetch, basically as a back-end database.
• Manage those atoms as HGDB sub-graphs so that each user can have ownership of their own stuff that they may decide to share or not with other users.
• Maintain previous versions of atoms.
• Implement the notion of an update that updates a set of atoms (a subgraph) as an atomic operation that is timestamped, possibly with a comment etc. (like version control commit) and potentially reversed.

= Starting a Seco Server =

The main class is seco.server.SecoServer. It expects a single argument that is a JSON configuration file looking like this:

{{{ { "interfaceType" : "org.hypergraphdb.peer.xmpp.XMPPPeerInterface", "localDB": "/tmp/secoserverdb", "peerName" : "SecoServer", "bootstrap" : [ {"class" : "org.hypergraphdb.peer.bootstrap.AffirmIdentityBootstrap", "config" : {}}, {"class" : "org.hypergraphdb.peer.bootstrap.CACTBootstrap", "config" : {}}, {"class" : "seco.talk.SecoTalkBootstrap", "config" : {}} ], "interfaceConfig" : { "user" : "SecoServer", "password" : "password", "serverUrl" : "yourserver.com", "room" : "hg@conference.yourserver.com", "autoRegister" : false } } }}}

= Implementation =

The classes implementing a Seco server are in the seco.server package.

The server is essentially a peer that exposes some "services" in the form of P2P activities that can be initiated by its clients. The services let clients store subgraphs of whatever they want and retrieve it later by some form of lookup.

Because each client peer can potentially have any sort of custom type they want, with whatever 3d and 4th party dependencies that they may have, it would be impossible for the server to properly load client atom. So the server can only manage graphs at the storage level (serialized atoms). On the other hand, we do want to allow some form of indexing of atoms to occur at the server so that clients can do interesting queries without having to know the handles of the atoms they want to retrieve.

The other issue with typing is the mapping b/w Java classes and type handles. Because each peer generates its own HGDB type out of Java classes, even for common classes (like HashMap for example), the HGDB type handles will be different. Therefore, for a storage graph to be usable at a peer, it must carry information about that HGDB Type <-> Java class correspondence.