Development

Posted by Gustavo Muslera 16 Sep 2003 01:50 GMT-0000 posts: 49 ☆ ☆ ☆

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.