I’ve developed my CMS a bit further than last time, as it now works with images and can store user settings (such as password, etc.) in a data file on the server. Since my CMS is intended to operate without a database, it’s essential that all of the information can be stored and updated on the server, but only in file format.
See it here.
user: thomhines
pass: pass
Todo
- Some sort of media manageer so that images, PDFs, etc. can be linked to easily from within the browser window.
- A multi-user permission systems that will allow for different users to have access to only content, styling, page structure, etc.
- A way to store drafts and/or versions
- Smart, inline editing that will allow the content editor to feel like he/she is actually editing the page.
- Smart phone optimization
- Standardize theming system to allow for quick changes in style
- Collaborative editing?
- Automatic install process
- Site manager
In addition to all this, I need to get it onto a few sites and test it thoroughly. In order to make sure I can get enough testing, I’ve decided to break the development down into several sub-versions, which I will make available as I go along. I’ve also set up the file structure so that the core files are stored separately from the settings and content, so that upgrading should be as simple as replacing the core file folder and the new features should be integrated right away.
Needs
The more research I have done, the more I can see the advantages of a system like this in certain, somewhat specific instances. First of all, MySQL and all the relational databases that drive all the common CMSs are generally slow(ish), and when operating under heavy traffic loads or on a server with sparse resources, can slow to a crawl or even crash. I ran across this an article earlier today (http://carpeaqua.com/2011/04/05/recipe-for-baked-wordpress/) that talks about how to ensure your hosted version of WordPress can survive a large influx of traffic. The advice isn’t difficult, but it is above many people’s heads, and even if it wasn’t, people clearly aren’t following it. The takeaway of the article: If you can’t or don’t want to do this, don’t bother setting up your own WordPress install.
Furthermore, there is a movement of people who are completely against the use of MySQL in almost any capacity. Called the NoSQL movement, they think that for sites, large or small, there are better solutions, including flat file CMSs like the ones listed below:
Prior Art
Razor CMS
Pluck CMS
Pivot Blog
Lotus CMS
Skeleton CMS
Cushy CMS
Also, I found a couple of patents that are somewhat related, but not much in the way of dynamically changing flat files on a web server.
http://www.google.com/patents/about?id=sk42AAAAEBAJ&dq=content+management+system (1981)
http://www.google.com/patents/about?id=dySXAAAAEBAJ&dq=content+management+system
http://www.google.com/patents?id=1-CDAAAAEBAJ&printsec=abstract&zoom=4#v=onepage&q&f=false (2001)
andywallace 10:06 pm on April 11, 2011 Permalink |
I wouldn’t necessarily worry too much about getting the readings. You could make a very viable prototype just using simulated readings. Somebody else (Scott I think) suggested just using RFID tags to represent the different readings a user could have (high, low, medium) etc.
Having it use real readings would make it difficult to demonstrate anyway since you’d pretty much have to kill your boyfriend to show the creature when it’s really sad or unhappy.
Oylum 10:09 pm on April 11, 2011 Permalink |
Your research is getting detailed and you are finding new stuff each time, which is really great. But I think you should start prototyping your project from now on. Sometimes the assumptions fail so bad when you prototype it and it will definitely happen to you. You cannot make sure which direction to go, how to continue this project unless you have something working even if it’s not working perfectly. I suggest you do some implementation prototypes and blend it with look and feel for the next step.