Be able to map objects to an Engine.
Two types of mappings:

• local bindings, which are not known to other engines
• Network bindings, that can be used by other connections

for Object Linkers that supports object registration (thus, a lot of them), add an InitialisableNetworkObjectLinker[R <: NetworkObjectReference] trait that contains a method initializeObject that will be called once a NetworkObject with matching reference is received

Currently, it's quite impossible to define its own Network Object Linker and to integrate it into the GNOM System.
Also, it should be much more easy for the user to retrieve an object from the reference.
Maybe making a MapNetworkObjectLinker that simply maps references to objects/presences.

Current informations only let the user know if a network object is stored on an engine id with the requested reference.

NetworkPresencesHandlers should be able to provide this kind of infroamtion to the user :

• the object's type
• the object itself (if allowed)
• the object hashcode
• the object class's checksum
• is the distant object the same (class, hashcode, type, etc or equals) as this object for all engines (or one engine, or a list...)

Example

val linker = network.getGeneralNetworkObjectLinker
val presence = linker.getPresence(PacketTraffic / 0 / 7 / 5)
val friend = "Engine01Identifier" //the engine's identifier we want to extract informations
val isPresent = presence.isPresentOnEngine(friend) //true if the engine has opened any packet channel at 0/7/5
if (isPresent && presence.sameClass[MessagePacketChannel])) {
     //we are now sure that the engine have opened a MessagePacketChannel that we can use directly and use to send a message
      val channel = traffic.getInjectable(MessagePacketChannel, ChannelScopes.retains(friend))
      channel.sendMessage("Hello, Friend !")
} 

Create a diagram that explains how the GNOM System is made and how it works

• Show an overall view of the network
• Shows Shared Caches part
• Shows Traffic part (packet channels and Contextual objects)
• Show how the persistence uses the Object linkers
• Show how Object Network Presences Handling works

Add doc for all classes that figures in api.gnom.*

Finish the wiki that explains :

• The reasons of why the GNOM has been created
• GNOM overall concept, problems that the system solves and possibilities it adds for the user
• Network Objects
• Network Objects Reference
• Network Object Linker

Summary

Be able to create synchronised objects that only perform RMIs when its methods are called. A full remote object have no initialised fields, because they are not used as they are meant to deflect invokations to other engines. Thus, it would be possible for full-remote synchronised objects to directly extend interfaces.

Enhance ContextObjectReference in order to match more kind of ObjectReferences. Actual COR only match another COR with the same ID.
Here is some examples of applications of the enhanced CORs:

val col = channelNode.config.getCOL()
//all network objects refered by a TrafficPresence and that is contained by any sync object are to be replaced by the alternative
col.bind(TrafficReferrence containedIn SyncObjectReference, alternative) 
//all objects extending or implementing `MyType` are to be replaced by the alternative
col.bind(ClassReference[MyType], alternative)
//All objects that extends or implements `MyType` and verifies the check are to be replaced by the alternative
col.bind(ClassReference[MyType] thatVerifies(x => verify(x)), alternative)

Summary

Be able to configure in the PersistenceConfig how different error or situation occurred during an object serialisation or deserialization should be handled

Goals

• Enhance the flexibility of the program
• Enhance the user's control over security
• Help the user to write an application that can communicate with applications of another version.

Motivations

The feature can be very interesting for runtime-added classes (Java modules, plugins) or for engines that runs an application
with different versions (ex: Server/Client).

Classes that does not exists on the current engine

If an engine receives a packet that contains

val config = new PersistenceConfigBuilder {
     on unknownType "org.myapp.component.*"            λ (tpe, remote) => null //null will be used instead
     on unknownType "org.myapp.player.*"               λ (tpe, remote) => UnknownObject(args) //UnknownObject alternative will be used instead
     on unknownImplementation[MyInterface]             λ (tpe, remote) => StubImplementation(args) //use a custom alternative
     on unknownTypePersistence "org.myapp.component.*" λ (tpe, args, remote) => remote.askPersistence[UnsafeTypePersistence] //We will ask to the sender if it can send a version of the serialised object, serialised with an UnsafeTypePersistence
     on failedObjectPersistence "org.myapp.*"          λ (tpe, args, failure, remote) => throw failure.exception //throw the catched exception
     on reference[TrafficReference] containedIn[ContainerObject] λ (obj, remote) => new Alternative() //all network objects referenced by a TrafficReference that are contained in any objects of type `ContainerObject` are to be replaced by an alternative
}

Summary

Create a SyncInstanceCreator that can replace an object directly in the memory, in order to
Enhance the injection of a synchronised object by replacing the source object by it's synchronised version.

Goals

• Ease the control of a program by injecting sychronised object more easily
• Deal with limitations of the current SyncInstanceCreator implementations

Motivations

Current implementations and their limitations

There is two default ways to create a synchronised object using SynchronisedObjectCache#syncObject(int, SyncInstanceCreator )

• Using a Content Paster :

val player: Player = new Player(new PlayerHealth, "John", "Cena")
val playerSyncs = cache.syncObject(id, ContentPaster(players))

The ContentPaster will basically paste all the fields of the player object to the synchronised object instance (playerSync).
This will have for effect to possibly modify the player object when the playerSyncs will get modified, and vice-versa.
However, as the player and playerSync are two different objects. And if a non-pure method is called (such as Player#setName) on one of those objects, the other one will still get the old name reference. Consequently, the two objects could get modified by the other in a pretty random and incomprehensible manner.

• Using a constructor :

val syncFile: File = cache.syncObject(id, SyncConstructor("C:/any/file/text.txt"))

This is the most clean and safe way to create a synchronized object, However, this option does not allows the user to synchronize an already existing object. Of course, you have the ContentPaster, which support this, but, as said above, if the source object still used, some uncontrollable modifications would be received on the synchronized version, which is not acceptable.

The Replace implementation

Well, the concept of Replace(source) is not that hard to understand : Once you get the source object you desire to synchronise, using the Replace SyncInstanceCreator will replace the old object to its synchronized version.
Here is an example :

val cache = manager.attachToCache(id, DefaultSynchronizedObjectCache)
val source: Player = list.get(winnerIndex)

assert(source.getClass == classOf[Player]) // the object's class is Player
cache.syncObject(x, Replace(source))
assert(source.getClass != classOf[Player]) //The object's class is now the PlayerSync (and not directly Player)

Complications

As the Object Layout and memory management is not part of the Oracle's specifications, each JVM have a different way to define it's object layout. This way, it is not possible to define a static code that would work on every JVMs; the "Write once, Run everywhere" feature of java will not be usable for the Replace implementation.
Some native code would certainly be necessary for this task, but i've personally tried to write some native code, and i did not found a way to get an object's address. For the Hotspot & OpenJDK implementations, there is the JOL library that can do this, but it's using Unsafe, and this class will later be removed in next java versions.