Development

For fixing ideas, lets separate code from presentation from content. Code are the php scripts, presentation are the templates for smarty, and what I will discuss here is about core data for the content. There are more core data to be represented, like users, groups, security, etc, but I will start from the inner core of generic data for content.

Of course that this is not thinked as an implementation way to do things, just modeling, performance, data representation and querying in sql databases and things like that are for other moment.

My proposal is to have an inventory of content objects, each one having the following attributes:

• id
• name
• kind (a wiki text, an file, an image gallery, a forum post, an entire blog, etc)
• list of attached objects (ids/names/etc of objects attached to this)
• owner (as in user owner or creator of this object)
• category (could be also list of categories)
• father (the object from where this comes from/is attached to)
• security scheme (list of permissions of this object in special related to users, or groups)

Of course, this are not just a table columns in a database, is just a conceptual level, the lists in here could mean more tables, or a field with special separators.

Note that under this structure, is perfectly valid to have a forum attached to a forum post (forum management software could enable or disable certain attachs, but the structure is open to such things) or to have the same object as attach of himself (also, the software could control that this not happen)

The "kind" of object, is, of course, something very open, an internal or external modules can define its own "kinds" of informations, with its own tables to help interpretation of objects.

Such table could be similar to:

• kind
• description
• handlers for
  • creating
  • destroying
  • editing
  • showing stand alone
  • showing attach
  • showing module

Of course, there is some kind of inheritance between levels of objects. If i.e. you delete a forum, it call the handler for deleting each one of the posts, which in its own time call de handler for deleting the texts and the attached objects, and so on, and then call the handler for deleting itself.

Now, how this kind of structure could relate to "actual" tikiwiki? How we can represent with this kind of things i.e. Wiki pages? Well, we have a generic object, of kind i.e. "text" or "wiki", and in a table for texts, where we have as fields the text itself, and logical values "contains wiki", "contains html". The wiki display program should check for that name or name+wiki, display the text of the texts table (rendering wiki and/or html depending on the logical fields), and for each of the attachment, call the appropiate handler to show as attachment the related objects. I could even put a table specifically for wiki in the middle, so a component of the new table could be the id of the text in the texts table, and have more related attributes, like the list of objects that is the history, or a list of special content that have this page inside, like a list of links or used plugins, if someone finds that this could be useful.

As a side note, Categories could well be content objects, ie., don't need to be an attribute of every object, but could be an object by itself, with all components being objects attached to it. This could have a positive impact implementing things like security (the security of an object could be checked looking at its own security attribute, and the all levels up)

How security could be managed in an extensible way? The actual scheme have two approachs, security by feature (i.e. that user/group can access forums) and security by content (i.e. for wiki pages you can decide who can or can't access to a content, or do some things with it).

In the content objects approach of data, there is a "security scheme" field. For any object, you'll have a list of permissions regitered, i.e. can edit, can see, can attach objects, can delete, etc, list that could be common, or maybe specific for a content type (is different see, edit and fill a poll? well, then for the hipotetical poll object will be a "fill" security item).

In general, that scheme connects the available actions for an object, with people and groups. But there are permissions not related to content data, but in some way with other system data or system actions. That security scheme should be included in the structure that talk about those items.

How the permission should be represented? In the actual way to represent securiy, in general you have an 'feature_can_do_action' field and another for 'y' or 'n'. I was tempted to suggest that all features are by default off and have only 'feature_can_do_action' to mark that it is enabled, but that would give at least usability problems for inherited and attached objects. Is better to have things in the actual ways for an object when is specifically selected, and for others, that be applied system defaults or upper level objects permissions.

I think that using phpGACL or other alternatives will not change a lot this ideas, but whatever system is used, the basics that should do is to enable a dynamic set of permissions to be set for hierarchical objects in an implicit or explicit way.

There are also some implications in security if the implementation is as broad I suggest in TikiIntegration2. Lets think that users can define its "own" tiki, its own blogs, its own trackers, etc, sepparated from the system ones. Maybe we want that users could be able to do so, but in the other hand, we don't want that normal users create system objects like forums or things like that. That will be solved with "root" objects, one for the system, one for each user, one for each category, that can be set with system defaults, user groups defaults or security template schemes.

This started thinking in posting something about Core and Users. After all, users look like something that should be in the core, at least to support security. What will be the core users data? I think that nothing more than username and password, but modules and extensions will modify the user database adding fields, or have more tables for additional data (i.e. the avatar, or geographical data, or even site specific data that the administrator wanted to add, that with maybe a form editor extend the user data to be able to hold more site specific info).

But, what about having the user data put along with the content data? and be extended in a similar way? You could have a core "user" class, that have a username and a password attributes, and extension of this class have more data... and my thread of thinking started to follow the problem of relating the additional user data with the "real" user for all the features and extensions. Then I thinked... why not have extensions of the "user" class with names that extend the original class? i.e. to have a content data of the class user.avatar, that is the extension of the user class, where the "basic" data have as key the username and the "user" class, but the avatar info is in another record with key the user name and the "user.avatar" class.

The topic of names and namespaces is something very common in my postings, have something about this in TikiNames_gmuslera, something more in TikiNameSystem, and more in some of my writings, including TikiIntegration2, so the idea of having an hierarchical namespace for class names is an evolution of all of this.

But... how many namespaces? or a single one? or a common way to say that a name belongs to some namespace in particular, or is some kind of object? I think that all of this discussions could give us a way to have an unified way to use names for Tiki objects, in the most broad sense, and most of this discussion not have to be just for core.

There are a lot of ideas that derived from this, some for actual tiki, and some that will require development from core:

• Have a "resolver" of names, something that could be tiki-index.php or what apache redirection points to after a url with some kind of parameters. That should search in the namespaces to see what object fits better. This could be enhanced using more names in the tiki objects (i.e. instead a gallery number, to have a name for them.
• A result of the previous one... why not have wikified names for all objects? Something like a name for URLs, and a description-like name for showing/listing/etc.
• What about having namespaces a la perl? with a character at the start to define what namespace applies there, like $awikipage, @aclass, ½anuser or things like that. I think on in to have different characters for a blog, or an image gallery, etc, but then I realize that there is not enough printable, non-reserved chars for the amount of actual or future kind of objects.
• Another alternative, to have names, like class.wiki or user.gmuslera, or .things like that. The names could be core names or evolved names, like user.avatar.gmuslera or user.gmuslera.avatar, or a more objectoriented-like syntax like user.gmuslera->avatar or alternatives with a URL friendly charset.

In general, I think that having hierarchical namespaces for most things in Tiki is a must. Some names could have context related shortcuts (i.e. when I'm talking about classes something without prefix should be a class name) or prefixes/suffices that discriminate namespaces or kind of objects. And even the namespace could be a common one, and with this in mind, most objects could be stored in the objects database, with a common name that could be key to refer to it and obtain attributes.

Been thinking a bit lately in this kind of topics, and had some ideas that don't fit clearly in any category... and maybe are bad ideas but anyway, they can be useful for other people.

The idea behind core is the extensibility, and the system will be better if its more capable to be extended, either in flexibility and in how much easy it could be.

To be extended more easily, i thinked that should be some different ways to extend it (most of them, already availables):

• New modules
• Plugins
• a scripting language
• more?

Extensions could have different ways to plug into the system

• Inherit: a new extension creates a new object from another existing object, in a chain that must end in some core object and core functions.
• Extend: give new functions, bells and whistles to some existing module/object. You have the same object as before (i.e. a wiki page) with more functionality
• Replace: for the rest of the system you have new functions to interact with some kind of object. I.e. an extension that play with wiki pages in a new way, making inaccessible for the rest of the system the old way (i.e. the action editing a wiki page will call its functions for it). This kind of module could have a way to call the old module functions.
• Plug: more than extend, giving new functions, they append to old functions, i.e. save a wiki page will be the old function, but wull do more things, like sending mail, or writting a log.
• More?

Of course, templates for extensions that are written enabling this kind of extensibility is encouraged. Writing extensions that break that extensibility model could have undersirable results later.

This is related on how to generate new objects and functionality. Developers should have the freedom to not only create new kind of objects, but also be ablle to enhance and extend existing objects without creating new kinds.

---

Also was thinking in the several trees that are around the system. One is the object definition tree... there are represented all objects from core to very complex, and probably creating an ubercore object (from where all the core objects descend) is a good idea but there are more trees.

But what about content objects? Should all objects in the system have a common root or have just localized hierarchies (like a wiki page and its attached objects, or a category). I think that there should be a unique tree of objects, to have root/system objects and descending from them categories, subsites, user's trees. That could make things like hierarchical security and names around the system easier to implement.

But also there are more objects in the system... where to store the users? how manage them? users are one of the most obvious extensible objects, but have some properties that make them different from content objects... or maybe not. Have some meaning to create users not at system level, but at category level, wiki page level or user level? to enable a user to create/maintain his own subset of user base?

What about user groups? From one point of view, they are something related to security, a collection of users where some common permissions are applied, but be more uses than just security, like i.e. sending a mail, newsletter, etc to a group. What is clear to me is that users should have the capability of creating their own groups for at least the permissions for their own content. Groups, in fact, could be content objects stored in the same tree as normal objects, and for an object permissions could be appled for users and groups belonging to the same or upper levels in the tree.

What else? Security is not an object, but a property of most or all objects, but their effects traverses the tree. The permissions an user could have over an object are the ones that are explicit for that object, or implicit because they are applied to an upper level of the tree. But in the other hand, security includes also the ability of users to call functions, modules, actions... how that could be represented in that tree scheme? could be a property of the user, a property of the system, a "non printable" content data attached to a level or the descending levels. Could have some meaning to, i.e., don't create new wiki pages behind some level but not to upper?

---

Last, but not least, phisical storage. How to put trees of extensible objects in flat sql tables and extensions in files, directories and URLs? For now, having installation routines for the installation of extensions and creates its own tables for their new objects and attributes and trying to have normalized the base tables for core objects and integrity data should do the work with the databases and having an ext/ directory to hold extensions should do the same for the disk organization. Maybe programs that manage different kinds of information could be hidden from URLs, having URLs that look like /tiki/show.php?object=gmuslera.MyForum.Post.32 (or even /tiki/show/gmuslera.MyForum.Post.32) and based in the kind of object the system show it in the right way.

I'm having random thoughts about my random thougths , and thinking in the structures to store my proposed hierarchical tree of information, and having also a hierarchical name system proposed for that objects, looked interesting the possibility of storing all of this in the filesystem, instead of a sql database.

Think about it... having a directory (probably outside the web tree to avoid unauthorized acccess or accessing directly to the content) where all the directories are objects, and all the files attributes of that object. Attaching objects to any object will be mostly natural, adding a new handler for new propierties will be also in that data structure, just add another file with an unique name and thats it.

A wiki page could be a directory that have the name of the wiki page (maybe wiki.PageName if you want to give the kind in the name, or a file inside called "kind" that say inside just "Wiki") where you have a file named content with the content (or textcontent to make that different with binary content kinds), but also could have directory for each attached file or graphic. History could be represented with files named content.version or content.date or things like that. Other content types could be represented that way also, and programs that show them just need to call the handler for that kind, or handle know files in the directory. Could be directories for users, and categories, could be files describing the security scheme for the current directory, a lot of things

This could have a lot of advantages, would be easier to backup, to the admin work with the information outside the system, to batch programs to get information, process, convert, etc. Will be simple to manage and to understand, and, at least at some level, to build a tiki system over it.

But, in the other hand, it could have disadvantages? Processing the data as a whole could be messy. Searching will need another way to be done... a grep on the tree will not be good, maybe submiting to an indexer the content attributes could solve the problem (the names of the files will have all the path to them, so giving a piece of content the proper place is in the name. Another problem could be speed, if for each part of a big listing you have to get a file with the date, a file with the owner and so on instead of just obtaining a row of a query record, well, speed could suffer (or not).

But, anyway, look a nice model to look over it and try to visualize how data could be represented or stored.

Or could give another idea about database abstraction. If things are properly structured, the database access part could be deep in the core, and outer modules will not talk directly with the database or whatever it is, but with the data access modules. What if at this level I put something that enables to choose how to store content, like in a sql database, a ldap directory or the filesystem?

I'm a bit old-fashioned in a lot of topics, prefer HTML 3, not do a lot of OOP, and am somewhat slow to adopt "new" things, so I don't discard without thinking the idea of storing complex information directly on the filssystem, but, what you think about all of this?

So, basically you are saying that tiki should embrace a little from the zope/Plone style of content managment systems with regard to namespaces (directory style) and security on objects (overridable on every level)?

grtz,
Gongo

> So, basically you are saying that tiki should embrace a little from the zope/Plone style of content managment systems with regard to namespaces (directory style) and security on objects (overridable on every level)?

2 things:
- Parallel evolution is when 2 kinds of animals evolved to a similar form that fits better in a common environment (i.e. dolphins are similar to fishes, but they are not). Tiki and Zope/Plone are relatively close, so is natural that in some point of their evolution have points in common,
- Even if plone/zope didn't exist previously (don't know them at that level) I think that having a flat namespace is a limitation of current Tiki, so its the need of integrating all possible content object types in main tiki.

gmuslera:

take it even further: get rid of all the 'tiki-xxxx.php' files in core. It is all handled by the type of the container/object you selected and retrieved from the database (what class can handle it) load that one (the lib) and execute the rest of the options through the renderRequest ( $objectID, $myTikiCoreWrapper, $action )

since a typical feature on tiki is at least 3 files nowadays, and also 1 dir, we could eliminate this in half because we would not have a specialised php file, nor will a dir in the lib directory be needed anymore. (it adds up when you are hosting tiki in a hosting environment where a diskquota as well as a filequota exists.

You should make groups more like phpgacl ARO's

I mean: on creation of a user, a special group is created with a singleton user attached to it as well.

You'd have user (for instance gongo), belonging to groups
RegisteredUsers and "UserSingletonGroup:Gongo" or somthing similar that is not allowed for groupnames when you create groups, and so the groupname would not exist. It belongs to the user just as much as the user belongs to it.

When adding ownership, link to the group iso the user. For every object in the category/object hierarchy you create, allow ownership to be one of several: "UserSingletonGroup:Gongo" (logged in user's group), Anonymous group (not logged in) or any of the groups a user belongs to or any other group.

Access rights could be simplified in the case where you are the owner, or belong to a group that is owner of a certain object. You then have the access rights for all applicable actions of that object, without even any record being read or parsed for allowable actions.

If you are not in one of the owning groups, either implicitly or explicitly, you cannot assume permissions and you should parse the permissiontree to see if you can use something. Having no rights defined would result in a (soft) deny. Having a GRANT made on a parental object allows you to go for it. Having a DENY on some object and one group and later on a GRANT, grant will be the default action.

Having a grant and later a deny would result in a deny.

If on same level, then check the level of nesting: usersingletongroup is denied? deny right to action.
usersingletongroup is granted? grant right to action.

The one with the deepest nesting for the usersingletongroup is the one that loses out and the closest nesting prevails.

Anonymous is the parent group for all groups
It contains the anonymous user (the default when not logged in) and RegisteredUser.

RegisteredUser contains all UserSingletonGroups by default (they are added, and cannot be removed from it, nor can anonymous, admin and Anonymous/RegisteredUser).

User is only used to store user specific preferences and to create the extra group. Those preferences contain the tiki settings, the user's password, ...

Storing this data in the filesystem would also recreate nasty side-effects for those of us (tiki deployers) that use limited budget hosting.

On these kind of hostings, you would have next to a diskquota also a filequota. For instance, on the site I am deploying right now, it is impractical to install tiki for 3 subdomains (with their respective databases), even when I start from a same documentroot. The dq is 50MB (which I still think is enough for them to get past this year, but after installing tiki it turned out to occupy already 34MB. Adding 2 additional databases pumped it up to that amount.

But more dramatically would be the fact that they have only a filequota of 5000 files. With tiki being 3000+ files and subdirs, some site specific files and apache/php/mysql (3 times several table files!) , you can see that this leaves almost no room for template_c (for all 3), or session files for that matter. Currently am at 3900 files, and am stripping down tiki with the things I find unneeded. THAT is the biggest nightmare, because when I'm done with it, there will be a new release already ...

So ... ease up on the nr of files. A class file (or multiple if you really need to split the functionality) and some templates is all I need. And knowing what is dependent of what and what features I do not need to be removed easily (or better yet: if I need something, I can install it
later after a minimal/core installation!)

Limit the number of entry points to tiki as well. no tiki-view_articles.php/tiki-view_wiki.php/tiki-admin_xxx.php ... have just a tiki-index.php entry point that boots up the tiki-core, gets from its parameters what object type it is supposed to display and what class is associated with it, loads that class and fires up the specified function (overridden extension) associated with the command.

Easier to maintain templates also. Let everything link back to that entry point and let it figure it out what you mean (actually, this php files is not going to get very big, since it loads the tiki-core, adresses it to see if the object exists and if the user has the appropriate rights to perform that action on it they requested. Then if the object/rights and action exist, it queries the core for the appropriate renderingclass, after which it loads it, instantiates an instance of it and executes the renderRequest()

Nothing big ... just setup and delegate ;-)

What could be the path to develop the new core? Start from zero, loosing all work done till now, do some adaptations on actual code, or something in the middle?

My idea is that it be something in the middle. Start a design on how could be the next core, being aware of what was already done, and how, and in the other hand, start to adapt the actual development branch to make easier to fit on it.

The first part is yet to be started, or not, there are a lot of things already written for that goal, even some tentative implementations, but of all possible ways to code it, even doing it from a right, object oriented and very structured fundation, need to have some considerations on the directions/goals of the actual implementation. It should use smarty for presentation of content, or some other alternative similar to actual .tpls, be able to hold in a way or another most of actual content, be possible to arrange the layout of the page in a similar way as actual, and things like that.

The second is in a way or another also started. How would be the path to follow? Hardcoding less (i.e. what was done with the application menu), using higher level functions that hides details from actual code implementation details (like was done in code with the database abstraction with adodb or in the templates with the tikimodule smarty extension), using less arbitrary choices for sections of tiki (like the ongoing effort to normalize permission names) and so on. The trick here is to evolve actual implementation, maybe with easily done changes in all the suite, to maintain being functional (and maybe even more powerful in the process) but also easier to be adapted for a background change.

In that way, hopely, moving actual features to a new core will need maybe small changes and adaptations. Doing a mutual approach from the core direction and a current code direction the migration will not only be easier, maybe even will be the only way it could be possible