This is a simple CMS, and document framework. It is built inside the ideas of NoSQL and big data, but is a simple page renderer. The actual goal of the hosted project is self publicity and tech blog.
Iceline is a piece of software to be run on a webserver to build web resources. The libraries are capable of being run outside of the webhost, but would need reconfiguring.
It is a framework to allow management of HTTP headers, access structures, meta information, page templates, content human language selection, MVC structures, separation of content and presentation. It is to do as much of the mundane administration as is possible to allow designers to create websites/ web applications.
Over the long term, pages like this are what I would like this platform to allow you to easily and cheaply build. Most of this can also be achieved via wordpress or drupal etc. As a comparison, I was asked review viyali in Nov 2013, I hope to differentiate myself..

This is a process, not a product. I am creating things, testing them, deploying them; then repeating, destroying the previous structures if necessary; to add a few extra features. My goal is on this process have an expanding structure, rather than published assets. This process is common amongst webservices, but leads to code you don't present as glamorous code.


Please read :

  1. My spiral of development
  2. Docs for v1 resource format
  3. Docs for v2 resource format
  4. Notes for config file

[Update Aug2013]

I will hopefully be in position to abandon PHP 5.1 and PHP 5.2 as supported platforms before first quarter 2014. This means I can support current classloaders, PSR-01 and namespaces. When this happens I will move things around about, so code may be linked into Zend or Symfony without effort. I will add alot of interfaces, to allow a broader range of technology implementations.


  1. Why write this?
    1. Initially, I needed more PHP5 experience, and visible experience is more useful than hidden back office works;
    2. The site, to make my detail-centric CV smaller and lighter;
    3. To supercede and eliminate earlier code bases %;
  2. Okay, this is several years later, why now?
    1. Mostly as professional development. I am a stronger software engineer than a web designer;
    2. To allow a backstop against whatever poor engineering platform that other people are currently using;
    3. I would like to have a good platform to use in future;
  3. Surely it would be better to contrib to a larger project?
    1. I want to play with a few ideas;
    2. This is a tool in its own right;
    3. Over the larger scale, you are correct; but this is a thing I can put my name to, rather than a series of patches;
    4. I will also contrib to frameworks;
  4. Why is there no JS in the framework?
    1. To be more platform agnostic, one may add any JS frameworks one likes;
  5. You only support full HTML pages?
    1. Not true, please see examples;
  6. Why is this platform better than just a PHP interpreter ?
    1. There is a lot of effort put in, so what the site creator does is much simpler.
    2. This adds a lot of domain specific features.

% Thinking about this; this project, on completion encapsulates five earlier projects. I imported no source, but took the design and methods. I wish this to be the last one, it is the least rushed.

Why is it built like this?

  • Mostly because my second goal practising Agile structures;
    1. This is hard for me, and so good practice;
    2. As soon as I setup a PM software my activities will be clearer. I have a set of goals, and am doing iterative development;
    3. In the last quarter of 2013, I will be adding new technology, rather than supporting widely used standards;
    4. Many of the core v1 features where built as a site in a 5wd sprint. This was to free my attention for writing, which is more important;
    5. To view the code as a quality artefact, separate to the building process, is unreasonable for the early builds. I am not selling software. The later builds will have all the person-hours work necessary for a product;
      1. The quality of the design is improving, as I get frustrated with lack of scalability, or poor support for tools (I entirely deny a learning curve, but deployment of increasingly thorough artefacts);
      2. I will start using tags and real release numbers when there is more base work done, so everything is structured. I am publishing early and fast, on the basis I may get outside opinion;
      3. Please wait for a complete toolset;
  • Why do I write in lists all the time?
    1. To attempt to prune unneeded words;

If you read iceline source code, you may see functions named something like XXX_something. These are all executable placeholders, and will be eliminated from later builds. This lets me quickly add new features, but entirely acknowledge the requirement for more work.

Why would I (the reader) use this?

  1. The more mature projects (such as wordpress) don't fit your requirements.
  2. This project represents hundreds of hours of work, which you won't need to apply to anything you do your self.
  3. You are a designer ~ not an architect ~ and core structures aren't your strength.

Human Languages

Computers have traditionally been poor at supporting the full range of human languages. Until recently to have good computer support for your language you needed to have strong international trade agreements, integration with the international banking and a strong international presence. At this point you are probably fluent in en_US to talk with US business people, and so could use an en_US linguistic system.

Over the last six years my local systems are now support Unicode properly. That is anything I do may be in Unicode, and it will work. I do like being able to copy and paste any human language correctly, I read wider than I may type on a en_UK 101 keyboard. I am aware that other systems did this earlier, I have been using Unicode supporting systems since 1999, like Java. Personally, unless your log files support it, and all the other “not headline” tools, I would favour the older standard.
Older versions of HTML supported characters outside of ASCII127 by HTML entities. That is a multi-byte text encoded symbol, rather than native multi-byte symbols. The additional range of items was weak on typographic glyphs which I am now able to add into my content to support proper typesetting.

However, I wrote this section as a justification for adding all the data sections that duplicate information in a non-constrained fashion. There is support in the standards for allowing Unicode in domain names, in URIs, and certainly as HTTP GET or POST name and values. However it is support for, not native use; it is normally horribly clumsy. On this basis I favour simple and reliable naming schemes on the more computer centric sections of the platform like URLs, this is my leveraged solution. As this is a GUI, all the buttons may be in a language of your choice. The additional data items allow editing from the convenience of your normal editing tools.

A more thorough article on this in PHP is written 1. All of the resources and testdata shipped with the code bundle are in Unicode/ UTF-8.

On completion, iceline should:

Please note, the processor for the dynamic functions defined inside the resources them-selves will capture all the PHP warnings that are in the resource. Please write clean code.

  • Support static and dynamic web resources;
  • Support common internet formats (limited to open source ones, no expense should be necessary to run this);
  • Be standards compliant/ encourage standards ;
  • Be supportive and friendly with small devices/ mobiles;
  • Provide mechanisms for creating applications ;
  • Provide “widgets”, so applications are a few lines of configuration & the branding CSS to style it;
  • Provide multi-lingual mechanisms (so there can be a version for each locale your site is published to);
  • Support user identification and session tracking;
  • Support access permissions and restrictions;
  • Support partial documents (for AJAX/ AJAJ);
  • Support caching of each computed step;
  • Be runnable on any webserver that supports htaccess & PHP;
  • Make creating attractive forms easy;
  • Support shopcart type features;
  • Support finance/payment systems, as far as this doesn't conflict goals;

What iceline is not likely to do

  • Be visible, in the result sites;
  • Provide lots of JS (jQuery is a better, more supported library). I like JS, I use it judiciously, but it is specific to each application, so not a library;
  • Provide hosting plans;
  • Be a “single click site builder”, this is reduction in administration; I abhor tools that limit artistic freedom;
  • Be hosted inside another coding language (I don't see the benefit in rewriting everything, PHP is widely used, and installed);
  • Tell you what to do, in terms of DB, or similar extras;

Usecase for this CMS

  • The most important one is to be able to publish static technical content, similar to CPAN. This is separate to the ob website, which is the current content.
  • As the features of format2 stabilise, to be able to build dynamic websites.
  • To be able to build subpage sites (i.e. use AJAX).
  • Future builds will be able to create template emails.

Comparison to other platforms

At present this is under development. I recommend the use of more mature platforms.
At full features, in the future; the goals of “open source” mean I still recommend the larger projects, as they have better community. In terms of glamour, this is a shame; but wealth of the commons is a better basis for development. The community is stronger than an individual.
As I am implementing the rest of my ideas, the features comparison between the different systems becomes more blurry. But to repeat earlier lines, this is a developers tool, not a thing to make designers unemployed.
In theory my design is better at security, but until it has complete features, and it is given the same use as Drupal or wordpress; this statement is a promise.

The iceline source is hosted on SF

Document model.

If you need to mark a site down for maintenance, create a file called 'notice.html' in the doc root. The software will render this as a page rather than whatever the server is setup for. Future builds may allow more of a framework, so you don't need to set the whole document.

Project directory tree

If you view this as a source bundle rather than a website you may see the following ::


Test resources

Included in the source is a all-get resource to attempt to run all the do_get functions, to make spotting errors in designer resources more transparent. A similar do_post isn't practical, as the single resource can't invent all the necessary POST param.
There is a mirror resource, for application testing, to make it easy to see what parameters are getting into a resource.

Test data

If you are running on “my test machine” the logging writes everything to disk. Otherwise the logging is discarded to avoid disk saturation. “my test machine” is defined in the config file, if you search for MY_TEST_MACHINE, and change the listed IPs to whatever your local interface is. The internal hyperlinks will work correctly if you set “site_baseurl” to whatever your machine is using...

At present, there are test data to cover nearly all of the inputs to iceline as a piece of software. This allows the majority of the code to be executed ahead installation anywhere, and so all the obvious errors detected. There aren't really unit tests against the individual classes, due to the code being quite simple, and the difficulty in reducing dependences to demo each class. Each test case would require the creation of a large amount of code. As the amount of decision-making increases, I will build unit tests in normal fashion. I think they will be necessary as a precursor for the proper data channels (scheduled for v2.5). I need to build a complete set of tests for multi-language support, that is any of the internal string manipulation is stable for multi-byte.
There is test data in the directory 'test' in the source bundle. Please do not add the test resources (named 'sample-*') to live websites.
This functional test data covers both file formats for v1.X and v2. These will be ported to sensible framework before version 2.3. The majority of the possible options ~ by design ~ are stored in the page resource.
In future I will add “example resources” which are resources demonstrating and documenting features of the platform. They will be named 'test-*', and be access group 4. This is to allow other less technical designers create sites within this platform.

I have created the following test data, I need to make many more before the software is complete.

  1. runner-001-simple-wiki-get
  2. runner-002-simple-img-get
  3. runner-003-bad-file-get
  4. runner-004-simple-post
  5. runner-005-bad-db
  6. runner-006-bad-eng
  7. runner-007-simple-js-get
  8. runner-008-valid-language
  9. runner-009-invalid-language
  10. runner-010-cleverwrong-engine
  11. runner-011-text-engine
  12. runner-012-engine-absent
  13. runner-013-absent-res
  14. runner-014-locked-res
  15. runner-015-5.2.17-bin
  16. runner-016-docversion
  17. runner-017-method
  18. runner-018-codeversion
  19. runner-019-name
  20. runner-020-strapline
  21. runner-021-empty-get
  22. runner-022-empty-post
  23. runner-023-good-css
  24. runner-024-good-js
  25. runner-025-empty-nextGET
  26. runner-026-empty-nextPOST
  27. runner-027-bad-nextGET
  28. runner-028-bad-nextPOST
  29. runner-029-method2
  30. runner-030-empty-css
  31. runner-031-empty-js
  32. runner-032-language-and-mode
  33. runner-033-unknown-language
  34. runner-034-installed-language
  35. runner-035-empty-strapline
  36. runner-036-accessgroup0
  37. runner-037-accessgroup1
  38. runner-038-accessgroup666
  39. runner-039-absent-author
  40. runner-040-long-author
  41. runner-041-unicode-author
  42. runner-042-email-and-author
  43. runner-043-high-codeversion
  44. runner-044-low-codeversion
  45. runner-045-text-codeversion
  46. runner-046-empty-docversion
  47. runner-047-has-keywords
  48. runner-048-method-either1
  49. runner-048-method-either2
  50. runner-049-method-postonly
  51. runner-050-unicode-name
  52. runner-051-robots
  53. runner-052-get-edit-content
  54. runner-053-get-edit-titles
  55. runner-054-get-edit-next
  56. runner-055-get-edit-doget
  57. runner-056-get-edit-request
  58. runner-057-right2left
  59. runner-058-url
  60. runner-059-getopt1
  61. runner-060-getopt2
  62. runner-061-getopt2
  63. runner-062-getopt3
  64. runner-063-getopt4
  65. runner-064-getopt5
  66. runner-065-getopt6
  67. runner-066-viewsource * tends to segfault
  68. runner-067-wiki1
  69. runner-068-wiki2
  70. runner-069-uncode
  71. runner-070-html-insert-01
  72. runner-071-html-insert-02
  73. runner-072-html-insert-03
  74. runner-073-html-insert-04
  75. runner-074-footer-01
  76. runner-075-noEscape
  77. runner-076-docversion-2
  78. runner-077-docversion-2 -- oops, naming wrong
  79. runner-078-docversion-3
  80. runner-079-docversion-4
  81. runner-080-php1
  82. runner-081-php2
  83. runner-082-php3
  84. runner-083-php4
  85. runner-084-php5
  86. runner-085-php6
  87. runner-086-php7
  88. runner-087-multi-01
  89. runner-088-multi-02
  90. runner-089-multi-03
  91. runner-090-multi-04
  92. runner-091-multi-05
  93. runner-092-multi-06
  94. runner-093-multi-07
  95. runner-094-multi-08
  96. runner-095-multi-09
  97. runner-096-multi-10
  98. runner-097-multi-11
  99. runner-098-data-post
  100. runner-099-noreceipt-post
  101. runner-100-unicode-title
  102. runner-101-multi-12
  103. runner-102-multi-13
  104. runner-103-multi-14
  105. runner-104-multi-15
  106. runner-105-reverseVersion
  107. runner-106-viewsource
  108. runner-107-viewsource
  109. runner-108-viewsource * tends to segfault
  110. runner-109-docs
  111. runner-110-searchpost
  112. runner-111-sitemap
  113. runner-112-longhome-segflt
  114. runner-113-reportError
  115. runner-114-tagCloud %
  116. runner-115-searchGet
  117. runner-116-jobSites %
  118. runner-118-links-01
  119. runner-119-header-chunk
  120. runner-120-file-chunk
  121. runner-121-plain-chunk
  122. runner-122-unknown
  123. runner-123-form-1
  124. runner-124-form-2
  125. runner-125-form-3
  126. runner-126-form-4
  127. runner-127-form-5
  128. runner-128-form-6
  129. runner-129-form-7
  130. runner-130-form-8
  131. runner-131-site-dead
  132. runner-132-emailhide
  133. runner-133-include-1
  134. runner-134-include-2
  135. runner-135-include-3
  136. runner-136-include-4
  137. runner-137-include-5
  138. runner-138-plain-entity
  139. runner-139-frame-01
  140. runner-140-include-6 ~ accidentally double numbered, so had to move this one up.
  141. runner-141-frame-02
  142. runner-142-frame-03
  143. runner-143-frame-04
  144. runner-144-frame-05
  145. runner-145-frame-06
  146. runner-146-frame-07
  147. runner-147-frame-08
  148. runner-148-frame-09
  149. runner-149-frame-10
  150. runner-150-frame-11
  151. runner-151-include-7
  152. runner-152-include-8
  153. runner-153-escape
  154. runner-154-qunit %
  155. runner-155-alternative
  156. runner-156-alternative
  157. runner-157-alternative
  158. runner-158-alternative
  159. runner-159-browser-capture %
  160. runner-160-reporterror1
  161. runner-161-reporterror2
  162. runner-162-reporterror3
  163. runner-163-escape-firstLine
  164. runner-164-escape-firstLine
  165. runner-165-escape-firstLine
  166. runner-166-escape-firstLine
  167. runner-167-table.1
  168. runner-168-table.2
  169. runner-169-table.3
  170. runner-170-table.4
  171. runner-171-table.5
  172. runner-172-table.6
  173. runner-173-miss.01
  174. runner-174-miss.02
  175. runner-175-miss.03
  176. runner-176-mime.01
  177. runner-177-sitemap.01 %
  178. runner-178-browser-capture %
  179. runner-179-quotes
  180. runner-180-bad-resource
  181. runner-181-csrf-01
  182. runner-182-csrf-02
  183. runner-183-csrf-03
  184. runner-184-csrf-04
  185. runner-185-csrf-05
  186. runner-186-csrf-06
  187. runner-187-csrf-07

Items marked with a '%' are test entries for a specific resource, as I was having problems configuring it. These probably shouldn't be included in the published source, if the resource isn't included in the source distributed. I will add some verification tools in future, so every resource is rendered in one hit.

The segfault occurs on large files being included in the source viewer. It doesn't occur on small files. It doesn't occur in the same large file rendered directly.
Will be resolved... Think this is something to do with Text::Wiki. If you have more than 30K of text in an issue in flyspray ~ which uses a wiki library ~ it will also fail to render.