Skip to content

Latest commit

 

History

History
128 lines (98 loc) · 5.99 KB

README-PLATFORMS.md

File metadata and controls

128 lines (98 loc) · 5.99 KB
Raw

alt text



Introduction: Platforms & Super Layers

First of all we need to explain how we have separated each large structure of the framework into two concepts: 'Platforms' and 'Super Layers'.
When it comes to code they are both the same, however the main difference is that the SuperLayers can be consumed by all Platforms (IE.: 'Communication' or 'Blockchain' Platform).

There is also another difference which is that the Platforms can consume each other in an incremental order from left to right, so that each Platform can consume all the previous ones. An example of this can be the following: The 'Fermat PIP' Platform will only be able to consume the 'Fermat COR' Platform, and the 'Fermat WPD' Platform will be able to consume the two previosuly mentioned Platforms, and so on.

The Super Layers behave in a similar way, in that they can consume each other in a descending order from top to bottom, so that each Super Layer is able to consume the previous ones. An example of this case is pretty straigtforward: The 'Fermat BCH' Super Layer is only able to consume the 'Fermat OSA' Super Layer, and the 'Fermat P2P' Super Layer is able to consume the previously mentioned Super Layers.

As a reference, please enter the [fermat web's] (http://fermat.org/) 'Architecture' segment, in which you will be able to see all the previously mentioned relationships.

Before we move forward with the other topics, we think it will be usefull to point out the Layout of the system, in order for you to be able to put alltogether the concepts of this document. This goes as follows:

  • Platforms ➡️ Layers ➡️ Plugins ➡️ Developers ➡️ Versions

Layers

Now that we have covered the two main aspects of the system's architecture (Platforms & Super Layers), we will go into detail about their components.

Within each Platform there are one or more Layers, and one of the main aspects of them is that they have the functionality to group up several 'Plugins' that have the same behavior.
There is another aspect related to this, which is that the Layers also act as Merchants in the way that given a specific request (IE.: We need to compare the exchange rate of two different coins) they will only consume the required Plugins (and only the required functionalities) to fulfill the request. //: # (lcommunication example)

SubSystem

Following Layers (see reference Layout in the Introduction) we have the Sub System Classes in which you can register all the Addons and Plugin's Developers.

Developers

This last group is the one that has the logic to deliver the best Version of the Plugin, with the possibility to perform Migrations (IE.: Update the Database of a given Plugin, update files, etc.)

##New Platform Generation

We will now continue to describe the Platform Directory Distribution standard for the Platforms on Fermat:

  • PLATFORM_NAME/
  • libraries/
    • core
    • api
  • plugin
  • addon
  • android
  • linux

As this is the standard, depending on the Platform there are many more features to include in this list.

###Platform Core Classes Structure

By default, the structure we follow for the Platform's Core Classes when we either need to register or create all the components is as follows:

  • AbstractPlatform
    • registerLayers
  • AbstractLayer
    • registerAddons/ register Plugins
  • AbstractAddonSubsystem
    • registerDevelopers
  • AbstractPluginSubsystem
    • registerDevelopers

Please keep in mind that in order to obtain a readable code, we create all the components alphabetically.

####settings.gradle Each platform mantains its own settings.gradle ordered by layer and component type.
Please keep the elements ordered alphabetically in order to make the code more readble.

  • Type (addon/android/plugin)
  • Layer name.
  • Name.

###Fermat Core Classes Structure //: # (Insert content)

###FermatSystem The FermatSystem starts all the components of the platform and manages them, here we have to register all the platforms we need for the framework.
In the build.gradle of the core we must also add all the pertinent references to the Platform's Core Modules. When you create a new instance of the fermat system, you must provide it with an osContext and an osaPlatform, this is the way we found to make the framework Multi-OS, each operative system can provide its own osa libraries and add-ons to use as needed.

  • FermatSystemContext The FermatSystemContext holds all the references of the main components of Fermat, it initializes all the Platforms taking the parameters mentioned in FermatSystem, it also allows you to add a new Layer to a given Platform.

This class also posses several methods which allows you to initialize several components such as: * _AddonVersion, addonDeveloper, PluginVersion, pluginDeveloper, PluginSubsystem, Layer_ or even a _Platform_ instance.

  • FermatAddonManager The FermatAddonManager class centralizes all the required service actions (Start, Pause, Stop, Resume) of the Addons in Fermat.

  • FermatPluginManager The FermatPluginManager class centralizes all the required service actions (Start, Pause, Stop, Resume) of the Plugins in Fermat.


It also allows you to get an existing or a new instance of the _FermatPluginIdsManager_.
  • FermatPluginIdsManager The FermatPluginIdsManager contains all the main functionalities to manage all the Fermat Plugins Ids.

This class contains methods that allows you to perform a number of actions such as: * Charge or Create Saved Ids. * Obtain a _PluginsId_ or even the _PluginIdsFile_, as well as registering a new _PluginsId_ or save a _PluginIdsFile_.