mariovaldez.net

I did not see these in your todo.xls sheet so I thought I would ask.

Any plans on:
1. Archiving of created documents and directories.
2. Posting all content directly in the database. (i.e. instead of creating folders and posting the files into them, posting the files directly into the database).
3. Letting a group have ownership of a document, instead of just one user.
4. The ability for the owner of a document to delete comments without deleting the original document.

Psymon:

> I did not see these in your todo.xls sheet so
> I thought I would ask. Any plans on:
> 1. Archiving of created documents and directories.

Do you mean "archiving" like a) storing old docs in a kind of repository when they become old, or b) backing up the directory structure?

If you mean a), then I've thought of it. All high-end CMS has archive management functions (aka document life-cycle management). I'll add it, but I need to think more about how it will work (from the user point of view).

If you mean b), then I was thinking on adding backup functions until version 0.7.6. Currently, the only way to backup is using the database management software (for the metadata/content) and backing up the root directory (for associated files).


> 2. Posting all content directly in the database. (i.e.
> instead of creating folders and posting the files into
> them, posting the files directly into the database).

This was a design decision I made a long time ago. I've reevaluated it again a couple of times, but I still think the current approach is the best.

During the first tests, I tried to store the files in the database, because I thought it would be easier to manage the data. But performance was poor. Really poor, the software was useless. I tested with PostgreSQL and Microsoft SQL Server and the results were the same: very poor performance. I increased the RAM of the server, upgraded the hardware, but the results were the same. For small files there was no difference, but for large files the server could not handle the load. Just for the record, the first test users were (and still are) storing large image files, logs, videos, analysis datasets, etc., usually files of several megabytes.

So I decided to store text content and metadata in the SQL server and files in the file system. After all, the file system is highly optimized to handle files, so this decision made sense.

However, I'm open to suggestions. Maybe in a couple of years computers will be a lot faster than today, and maybe the SQL servers will have optimizations to handle large datasets. By now, I think the file system is winner in handling files, specially large files.

Another topic is why to expose the directory structure. With this CMS module I was not only exposing it, but I was relying on it for the users to discover the structure of the CMS site. After several years of designing websites and general document repositories, I've seen that the hierarchical structures are the easier to discover and navigate. So I decided to leverage the directory structure of the file system by using it as the main structure of the CMS site.

This may seem weird to people used to topic-based/data-driven CMSs, where an article is not strictly bound to a rigid information structure.


> 3. Letting a group have ownership of a document,
> instead of just one user.

The needed database fields are alredy there to handle group-ownership for the documents. I didn't write the supporting functions because nobody asked for the feature before. It won't be difficult, so I'll add it in the next release (0.7.0).


> 4. The ability for the owner of a document to delete
> comments without deleting the original document.

Well, this is a question of ownership. I think the owner of a comment is the user who wrote it. Maybe in an informal facility if you delete the comments of someone else nothing bad will happen. But maybe your users would think "why to post a discussion comment if this person will erase it". That would stop flame-wars in your intranet, but may stop open discussions also.

Currently, user comments cannot be erased even by the author. Why? Because my main users wanted accountability: if you said something, you cannot deny it later (you can post a correction but you cannot erase your words). This may seems weird to lot of people, but the content in those setting was very sensitive and the comments were important review remarks and calls to action; they could have legal consequences.

I should write a global option to disable or enable this behavior because I think for most people this is not that important. Maybe two global configuration options like: "User comments can be deleted by comment author (yes/no) (defaul=yes)" and "User comments can be deleted by document owner (yes/no) (defaul=no)". I can add them in the next release (0.7.0).


So, thanks a lot for your feedback, Psymon.

What do you think?


Mario A. Valdez-Ramirez.

1. Archiving of created documents and directories.
- I meant a) storing old docs in a kind of repository when they become old. Definately a useful feature, especially since as more documents are posted the display begins to get cluttered. Although some type of access would still be needed to older documents. Perhaps two variables could be set, like max number of docs to display in subdirectories & max age of the documents. I have seen something in the config file about max age, but it never seems to do anything? Then maybe some type of archive for inactive documents.

2. Posting all content directly in the database.
- I completely agree with your choice. I didn't realize that it would slow the CMS down so much.

3. Letting a group have ownership of a document.
- I think this would increase the value of collaboration in the CMS, and open up new possibilites.

4. The ability for the owner of a document to delete comments without deleting the original document.
- I think this one is very necessary, I have seen people turn on comments then find out that when they change the topic the old comments remain (alot of users just want to edit an existing document, instead of creating a new one). So nobody uses the comments option. I do understand your reasons though. I think your proposed solution of giving options is perfect.