Go Wiki/CMS

From Adam Colton
Revision as of 15:34, 20 January 2014 by Adamcolton (talk | contribs) (Created page with "Thinking of rolling my own - bad idea, but hey, it's what I do. == Core == * Run on NoSql engines (I want to build it out so it can handle a few by default). * Security by d...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Thinking of rolling my own - bad idea, but hey, it's what I do.

Core

  • Run on NoSql engines (I want to build it out so it can handle a few by default).
  • Security by default - if no ssl, uses unauthenticated ssl
  • The core is halfway between a wiki and a CMS

I'm going to base the core data structure off the work I did for the [Immortal Object Server]. The "core app" is simply a mark-down engine.

Queries

I want to core of the engine to center around data, therefore being able to execute useful queries is critical. The primary method or organization is tagging. Tagging data puts it in a set. The basic form of query is based on set theory - union, intersection.

The first complication to this is set tagging, or subsets. This says that everything tagged B is also tagged A (though not everything tagged A is B). Therefore B is a subset of A. To make this useful we will want to bring in subset queries. This is accomplished with subset indexing. So A would be everything A (including all of B) but A[0] would only be things actually tagged A. A[1] would be things tagged A via one level of inheritance and A[0,1] would be anything tagged A directly or inheriting A via 1 hierarchy.

Symbols

  • +: union
  • %: intersection
  • -: difference

No order of operations, performed left to right.

 entrees + base % healthy

Apps

Following my fundamental belief, apps are divided into schemas, services, libraries and UIs. I also want to follow the WordPress model of having a core that does a single thing well and the system really gains power by using a set of apps.