Clone wiki

FULG / Manifest files

UNDER CONSTRUCTION

The manifest configuration files

There are two manifests?

Yup! In a FULG ecosystem there are two manifest files for totally different purposes but with a same perspective. The sole purpose of a manifest file is to give instructions to FULG.

Server Manifest

The server manifest.json file, also known as global manifest, is composed with instructions regarding patch or file availability. In other words it is the guide that FULG will follow in order to download the proper and available upgrades for your application.

Check the following example to have an idea on how a file like this is composed:

{
  "joker": {
    "os": { "win32": { "32": "w32", "64": "w64" }, "lin": { "32": "l32", "64": "l64" }, "dar": "mac" }
  },
  "patches": [
    {
      "from": "02",
      "to": "05",
      "description": "CoolApp 1.12.05",
      "notes": "This is the first patch.",
      "metainfo": "patches/meta/%OS%-02-05.moh",
      "data": "patches/%OS%-02-05.tar.gz",
      "date": "Mon, 01 Sep 2017 13:50:00 +0300"
    },
    {
      "from": "07",
      "to": "10",
      "description": "CoolApp 1.12.10",
      "notes": "This is the final patch",
      "metainfo": "patches/meta/%OS%-07-10.moh",
      "data": "patches/%OS%-07-10.tar.gz",
      "date": "Fri, 08 Sep 2017 23:50:00 +0300"
    },
    {
      "from": "05",
      "to": "07",
      "description": "CoolApp 1.12.07",
      "notes": "This is the second patch.",
      "metainfo": "patches/meta/%OS%-05-07.moh",
      "data": "patches/%OS%-05-07.tar.gz",
      "date": "Sun, 05 Sep 2017 17:10:00 +0300"
    },
  ],
  "current": {
       "version": "10",
       "description": "CoolApp 1.12.10",
     "notes": "This is the latest build of the application",
       "metainfo": "downloads/meta/coolApp-final-%OS%.moh",
       "data": "downloads/meta/coolApp-final-%OS%.tar.gz",
       "date": "Fri, 08 Sep 2017 23:50:00 +0300"
    },
  "files":[
    {
      "id": "file-010",
      "version": "3.2.1",
      "description": "File version 3.2.1",
      "notes": "This is a usefull new file.",
      "metainfo": "files/meta/coolFile-%OS%.moh",
      "data": "files/meta/coolFile-%OS%.tar.gz",
      "date": "Sat, 15 Sep 2017 03:30:00 +0300"
    }
  ]
}

The following table gives a quick overview of the objects and arrays contained in the previous example:

Object Name Sub-Object Name Quick Description Optional Accepts Joker Variables Accepts Path Sub-Objects Unique
joker Initializes the jokers that are going to used on the later sub-objects. x x x
patches Array that contains the available patch objects. They don't have to be in any kind of order or hierarchy. x x x
from Defines the source version of the current patch object. x
to Defines the target version of the current patch object.
description Gives a more reader friendly description of the patch target version. x
notes The famous patch notes string field. x
data Defines the path and patch file name. This sub-object is used by the web download method. x x
metainfo Defines the path and patch metafile name used by the P2P download method. This sub-object is mandatory when the P2P module is enabled. x x x
date A sub-object in rfc2822 format, used just for informational purposes. x
current Defines the latest build of the application. x x
version Defines the version of the application's latest build.
description Gives a more reader friendly description of the version. x
notes The famous patch notes string field. x
data Defines the path and current file name. This sub-object is used by the web download method. x x
metainfo Defines the path and current metafile name used by the P2P download method. This sub-object is mandatory when the P2P module is enabled. x x x
date A sub-object in rfc2822 format, used just for informational purposes. x
files Array that contains the available file objects. They don't have to be in any kind of order or hierarchy. x x x
id Defines the unique id or name of the file object. x
version Defines the version of the file object.
description Gives a more reader friendly description of the version. x
notes The famous patch notes string field. x
data Defines the path and current file name. This sub-object is used by the web download method. x x
metainfo Defines the path and current metafile name used by the P2P download method. This sub-object is mandatory when the P2P module is enabled. x x x
date A sub-object in rfc2822 format, used just for informational purposes. x

Note: The global manifest file must always be positioned on the root folder of the "patch" path set on the conf.json configuration file. The same rule applies for every OS root path if you are using platform or architecture specific web-servers. You can achieve this with the use of "path sub-objects".

You said that this file gives instructions to FULG?

Yes it does! But let's take a closer look at the previous example.
When your application launches FULG will firstly parse the version of your application and later will attempt to make a connection with the first available patch server and parse the manifest.json.
On this state, FULG, will search on the "patch-array" for the object that contains its version on the "from" sub-object. If the search finishes without finding the appropriate record then it will add to the download queue the "current-object". On the other hand if the search finds a "patch-object" it will add it to the download queue. Later it will cache the "to" sub-object in a variable named "tempVersion" and start the search on the "patches-array" from beginning until it finds an object that the "from" sub-object is equal to the "tempVersion". This procedure will continue until FULG will collect all the available patches needed from the "patches-array" and add them to the queue. When the "search for patches" procedure is finished then on an almost same manner FULG will start searching the "files-array". During that state, FULG will select from every object in the "files-array" the "version sub-object" and it will look into the version file for differences. The files that are proven different will be also placed on the download queue the rest will be ignored.
When the previous steps are completed then FULG will start to download the data files or meta files according to the queue list.

Patch Manifest

The patch manifest.json also known as local manifest, lives inside every Patch archive. It's existence plays one and only role, it lists the files that must be deleted after the patching process.

Check the following example:

//Warning: The following comments are used only for the shake of this example. JSON DOESN'T SUPPORT commenting.
//If you are going to use this example as a template then remember to remove them.

//This is an example of the local manifest file.
{
  //The version object exists only for informative reasons.
  "version": [
    {
      "date": "Wed, 19 Jul 2017 19:48:19 +0000",
      "version": "05"
    }
  ],
  //The unused object is the real reason of this files existance.
  "unused": [
    {
      "path": "tmplt/template/cart.html", //Your applications relative path to the file that must be deleted.
      "hash": "bec9f593a234286d1d1437df61201ccc" //This md5 hash is optional. Up to this version of FULG the files are not crosschecked before their deletion.
    },
    {
      "path": "tmplt/template/comms.html",
      "hash": "20b75c3011414bae40b367ec39ca8647"
    },
    {
      "path": "tmplt/template/fdeck.html",
      "hash": "18c15993b7b62bd7d8344f3bb98777b9"
    },
    {
      "path": "tmplt/template/googledc6d54306b92da0b.html",
      "hash": "5f3f37fdd0aff5ed35030c065dcd3451"
    }
  ]
}

Tip: If you are looking for a free tool to generate patch packages check out this.

Updated