Regards our project next steps

[mtmr0x]

We will split into some phases and in each phase, we will work on a different layer of the Chrondb.

The layers (for now) are:

• Communication: pretty much the protocol, how people would actually use us
• Main API Functions: stupidly simple, well-documented functions that are the interface to our internals, it must be human readable;
  • create DB
  • delete DB
  • delete directory
  • delete branch
  • list DB information
    • branches
    • directories per branch
    • etc
  • commit
  • get key
    • in specific branch/directory
    • on a date (range or not)
  • etc
• I/O: is called by main API functions and manages writing and reading from storage.

Project phases

Phase one

Total focus on Main API Functions, focusing on market solutions and delivering extremely high standards of user experience (which means no one should ask questions to understand how to run and use)

If it needs a user's guide, it's poorly designed.

Market solutions

• Irmin
• GIT itself
• are there more? Add a comment to the discussion so we can enrich it

How do we make decisions during this phase?

• If it deals with I/O in some way, we should not do it;
• If it deals with communication in some way, we should not do it;
• If it creates a basic git operation with great logging, simplicity, elegance and fantastic documentation, we should do it.

What are our goals for these Main API functions?

• Top-notch logging
• Simplicity and elegance over simplistic and complexity
• Extremely well-documented functions
• Similarity with GIT must drive our creations

How are we going to access and test those functions?

• REPL

Phase two

Focus on I/O, with possible adjusts on Main API Functions, not caring for performance. We need to store and retrieve information with ease and absolute resilience.

How do we make decisions during this phase?

• If it deals with communication in some way, we should not do it;
• If it deals with the Main API Functions, it keeps them elegant, but makes our life easier for working with I/O, we should do it;
• If it deals with the Main API Functions, makes them complex or dubious, but makes our life easier for working with I/O, we should not do it;
• If it works fine with I/O and let our creation simple, elegant, well documented and easily understandable, we should do it;
• If it gives some performance advantage, but it makes the system a bit complex, we should not do it, optimisations are coming in phase four;

What are our goals for I/O?

• Top-notch logging
• Simplicity and elegance over-simplistic and complexity
• Extremely well-documented functions
• Cover everything from Main API Functions regards its necessities from I/O

How are we going to access and test those functions?

• REPL, calling for the Main API Functions

Phase three

Focus on Communication, with design improvements on Main API Functions and I/O as necessary so we can have a minimal functional database. We have to choose one technology for it and do it well.

How do we make decisions during this phase?

• We should not look for performance;
• We should look for resilience and reliability;

What are our goals for the Communication layer?

• Extensibility: we should not code our internal Main API Functions or I/O layer for working with some specific protocol;
• Distribution: we should be aware of to whom we are distributing it and focus to make sure we satisfy those applications/developers' needs

How are we going to access and test those functions?

• REPL while in development;
• Through the chosen protocol using a specific tool

Next steps?

The definition of the next phases, which are a lot related to optimisation and much more improvements will be defined when getting further in the phases. We will run benchmarks and let the community drive our next steps.