I think that you may be dazzled with the dream of a perfect design. In the real world software construction, we may not consider an ultimate design which fit all our current requirements and our future plans. The most successful software is always those that issue a release with the basic functional sets as quickly as they can. After that we can start the evolution of the product. The refactoring concept is a good process for this purpose. They may launch 2.0 project, 3.0 layout, or even another independent branch with a much more radical sketch.

The primary goal is to release a stable 1.0 version quickly!

[ Edited by Highwind on 2002/1/28 5:41:59 ]

Sure. I'm just suggesting that module and theme developers could await RC3 before getting permission to go to town so that XOOPS developers can consider their own design for a classification system. Throughout the forums, you can see demands for a better classification system, even if they are not phrased in that way. I don't think a little patience is too greedy, given that this product was only launched in December and it's January now. Would waiting another month really be catastrophic if it led to XOOPS being a true CMS and not a glorified weblog.

Stephen

Just my idee.

But it seems to me this comment on XOOPS is getting a bit out of hand. Maybe AFLSC should take up his arguments directly with the dev team of Xoops. There always will be people with great ideas, but as far as i can read no one uderstands what the meaning of the story is about.

The XOOPS developers have done a great job and responses to my previous postings demonstrate that they think along the same lines and are moving XOOPS away from its weblog roots forwards to something much more exciting. Perhaps RC2 is more than just a code freeze and includes some exciting new developments, but if not then this is not the time to encourage independent module developers to start coding. Because you're basically freezing the potential of XOOPS if you guarantee forwards compatibility. I'll stress it again, XOOPS is fantastic at what it does and has a great future under a very talented programming team who do that most magical of all things, listen. Just don't put the brakes on just yet.

If there are developers reading this, don't feel any pressure to reply to this thread.

Stephen

(Happy that nobody has said the obvious yet: "Do your own bloody fork!")

i still cant read more than 2-3 lines
..
just release RC2

best regards,
netwize

I think you do have some valid ideas, but it's ultimately up to the developers of XOOPS to incorporate (or not incorporate) whatever they see fit. It will not be a solution for everyone; nothing ever is.

You are always free to write your own portal system/CMS *grin*.

- Mikki

That's the longest post I have ever seen on xoops. As long as that took to write out, the author probably got logged out in the middle of it. Maybe not.

I'm not currently active in development at the moment.

I think there are some interesting ideas there, but I don't fully agree that they all should be part of the 'core' content structure for all users. Also, some distinction needs to be drawn between what is a 'field' in the content table (id, title, etc...), and what is outside the table (e.g. max content length). I have been thinking about similar ideas myself for quite a while...

You do realize, I hope, that it would be a HUGE job to convert XOOPS to such a scheme. It would require not only core changes, but changes to EVERY module to be consistent with this approach. Perhaps the conversion can take place incrementally... For example, a first step could be to add common fields (with consistent names) to each of the content tables and them some central mechanism would know where to look for the info. (Each module or item type could have a flag indicating if it is 'compliant' with this schema.) This would pave the way for the full-blown scheme, and provide an easy way to write upgrade scripts etc... But again, *if* this ever happens, it is a *long* way off. (Maybe the other more active devs can give some insight into the long term plans, if any, in this direction?)

If you are looking for a unified solution *now*, I would suggest you have a look at the features of Drupal (php), eZ Publish (php), Plone (zope/python), etc which all follow an approach similar to what you have described.