i'll probably use a streaming processing model like jacksons' in java for XMLand JSON, to parse the HTML in an event driven way, relyng on the "marks" left by the attributes data-omega-loader-href and data-omega-loader-src on tags. That way, we do only streaming on parsing HTML / XML (the mechnaism is extensible to MJML), instead of trying to remembervalues with such things as pmongo db, or even just a big JSON kept in RAM by NodeJS inside the os process context.

I found https://www.npmjs.com/package/parse5-sax-parser , which is both purposed specifically for HTML, not just XML (loike the one i'm currently using), and is a SAX style parser, based on event emission

from grapejs-server.

Workflow

Actors

• the user of Omega

Initial Context

• the user has found an HTML 5 template on the web
• the user has created a github repo of URI $TEMPLATE_GIT_REPO_URI
• the user has versioned the template he found somewhere, inside the git repo, complying qith the following rules, the dev teams imposed him to approve his git repo access to an omega template repository.
• an omega template repository simply is a git repo, containing only two files at its root :
  • a json file named omega.json : this json object must have a given structure :

{
    templates : {
        'template1' : { /* The unique omega repository id of your template */
        title: 'A great starter template for our usual e-commerce customers websites ',
        git_ssh: 'git://github.com:Jean-Baptiste-Lasselle/grapejs-server',
        git_http: null /*  should be used for BOTH http AND https starting uris of git repositories */ 
        },
        'template2' : { /* The unique omega repository id of your template */
        title: "Our starter template for typical software product's github pages ",
        git_ssh: 'git://github.com:Jean-Baptiste-Lasselle/grapejs-server',
        git_http: null /*  should be used for BOTH http AND https starting uris of git repositories */ 
        }

    } 
}

each pair a set of git repos, that the dev team guarantees they are compatible with omega
*

from grapejs-server.

then :

• omega tries to load the template from a new repo, and that new repo will be added to the omega template registry if and only if the omega user validates he could properly work with it.
• So in an omega registry, every entry stands for a user validation, against a given version number of omega, so that the user managing the omega registry, has to sign his addition with a difgital signature used behind with git for signing commits and merge. Eventually, to make an omega registry completely independent of any git concept, I mean that its the omega.json file itself, that should be digitaly siigned, and I need to provide standard way with automation, to check signature.

How are signature checked?

• something public sould be advertised like download here this thing to verify my digital signature ...
• something that has to be made available by the signer, or a certificate authority : I'll have to check that workflow so that I know if I have to add metadata fields regarding signing and signature checking processes.

So all in all a registry is something people give you a gaurantee about : "Yes this thing that I provide, does workk properly with that other thing"

from grapejs-server.