Design of the POSIX Darwinet Engine

[Kjell-Olov Högdahl]

We have to decide if the first engine shall be in-process (statically or dynamically linked) or out-of-process (TCP/IP messaging, COM, CORBA, Interprocess messaging etc).

Either way, the Darwinet Engine Design goals shall be:

• It shall implement at least one protocol for remote Peer messaging.
• TCP/IP messaging
• Or e-mail using SMTP and IMAP or POP3 (No, I have not ruled this out yet).
• Regardless of protocol it shall exchange Message content using a BERTLV encoded vectors of data.
• The Domain handler shall handle at least one remote Peer and User (In total at least two users and two peers).
• The Engine shall provide an application interface providing access to a Domain (Implemented by an instantiated Domain Handler).
• The Domain handler shall provide the application with an interface providing access to a Domain View (Implemented by an instantiated View Handler).
• The View Handler shall provide the application with an interface to the Domain View MIV.

When the Application request a change of a value in the MIV the following shall happen:

• The MIV shall produce a delta if there is a change (the value actually changed)
• It shall report the delta to the Domain.
• The Domain shall engage the "Evolution Manager" to store the delta.
• The Domain shall engage the Domain Handler to distribute the change to the remote Peers.
• The Domain handler shall package the Delta into a BERTLV structure and send it to the Remote Peers.

When the Darwinet Engine receives a message from a remote Peer it shall act as follows:

• It shall provide the contained BERTLV and provide it to the Domain Handler.
• The Domain Handler parses the BERTLV and detects a delta.
• It shall engage the "Evolution Manager" to process the Delta.
• The "Evolution Manager" shall forward the delta to the Domain View for MIV update.
• The View Handler shall update the MIV and signal the Change to the Application though the Application Domain View Interface.

[JX]

These discussion forums are no good - I just had my post disappear.

Please put design in the Wiki as it is less likely to be lost and easier to link to other parts of the design.

You will need to implement most or all of this as I don't understand MIVs and so on fully.

[Kjell-Olov Högdahl]

My plan is to convey the design through the code if that is OK with you. I wish I had the time to write the documentation and the code at the same time but, there you go, time is limited :)

But I will try to find time for both. Ad I'll try to put some basics of the design into the wiki. I am not sure if that is the best place for it. How do we get it out into a document when needed? Perhaps there are wiki to document engines?

Another way to create documentation is to use doxygen or a similar tool to generate it from code. At least that would be a good way to document the actual source design?

[JX]

Doxygen is good - we use it at work and I have been writing my source code with Doxygen header comments. Not fully Doxygenated though - will need a bit of touch up with file headers etc. later.

As to the wiki, why do you need a "document"? Anyone who wants a to read the documentation can just look at the wiki, and I find that a wiki makes for MUCH better documentation than a document. Cross reference links, powerful search engine, the ability to have multiple pages open at the same time in a browser. I just find it so much easier to use than a linear document, even a web based one.