To fork or not to fork - that is the question

New Member Joined: Mar 09, 2004 Posts: 14

building on six's request is a suggestion, why not use mighty_y's forum news mod, but modify it so that the news could be displayed within the regular nuke interface in it's threaded, etc, forms, so the forum *could* be used, but wouldn't be required?

that way, phpbb word filter would also still apply

so essentially make it more of a nuke news module that uses the phpbb database for backend and also displaying the latest news discussions within the forum interface if so desired

that way it all stays integrated

as for html area, i hear the xoops dev team is working on something for a soon-to-be release date, it's a type of htmlarea but built for xoops, with BB-support so that posts aren't shown in html (for security)

*that* might be useful code for you guys to look at, and you could probably use a few functions for the nuke version

just an fyi

Hangin' Around Joined: Feb 20, 2004 Posts: 29

sixonetonoffun wrote:

News sorted by catagory, programable by catagory, start time and duration. Maybe even author.

I disagree.

IMHO many of the feature requests that are formulated like that simply miss the point. I guarantee you, the next day you present a news system with the above sorting capabilities to the world, a user will ask for a way to sort by a criterion you didn't consider, say by article ranking.

As the co-author and maintainer of the PHP-Nuke HOWTO, I have seen (and collected) hundreds of cases like that. I tried to give my answer in the HOWTO - that's why it is full of titles like "How do I do this....how do I do that". But a HOWTO is only one way to answer those questions.

Another way is to fork.

But if the new fork is designed with the same philosophy as the status quo system, then it will be plagued by the same problems, sooner or later.

How should a really new approach look like?

Like the following:

There is a class of "criteria".

A criterion is a collection of field names and rules.

A rule is of the form: ("field", "operator", "value")

A criterion object is an instance of the criterion class. It may contain zero or more field names and zero or more rules.

Criterions can be assigned to everything.

The News module has various criterion objects assigned to it. For the "purpose" of "type" "sorting", we will call the assigned criterion the "sorting criterion".

There may be other "types" of "purpose". The "types" are taken from a "type table", customizable by the administrator.

It is clear that the administrator must have allowed the "sorting" type, before this type can be used by the system.

Thus, the News module "has" a criterion of sorting type. The administrator can insert field names and/or rules in that criterion. Inserting the field name "category" into the criterion object, will have the effect that the articles of the News module will be sorted by category. Inserting also "date" will mean that they will be sorted by date too. There may be "attributes", like "ascending", "descending" etc. that may also be entered into the object - depends on the design.

In this model, your feature requirement is rephrased as:

News articles can be sorted by a finite collection of arbitrary field names, rules and attributes, to be previously specified by the administrator.

Do you see the difference? If you want "ranking" as a sorting criterion, just include the "rank" field in the criterion object from the admin panel. No coding necessary. A HOWTO (in the strict "how to" sense) becomes obsolete. You still need documentation - but it will not describe code hacks anymore.

That's a whole new way of looking at things. I would like to participate in an effort in this direction. Everything else is doomed to repeat the faults of the past.

Posted: Tue Mar 09, 2004 5:40 pm

nice, karakas

isn't that similar to the sqllite database model? allows the programmer (in sqllite's case) to decide *what* he wants each sql field to be with no specific rules (that's the impression i get from the sqllite feature page)

i like your idea, that's something that could be applied to everything...

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Chris, I could not agree more and this is the exact approach that I am referring to! It is not designing a certain type of module to do {x,y,z}. It is designing a 'module' class, if you will. We determine what are to be the different, (dare I say it?), OBJECTS Laughing

. Actually we determine the functionality of core and design the objects that will provide the functionality. No more will addons, modules, blocks, ever code for mysql. There should be a DATABASE Object, if you will, that all objects that need to speak to MySQL (or whatever rdbms) will talk to. Even though HTML is stateless, it will basically have a layer that 'listens' for someone needing the nuke_users table. As soon as the phone rings, the listener object/layer will signal the database object and will make the call and return it. Of course, the Security Object will have to be passed through first. Design - design - design! Then walk through. Then build.

Posted: Tue Mar 09, 2004 6:20 pm

Quote:

(dare I say it?), OBJECTS

can anyone say "XOOPS"? Smile

Posted: Tue Mar 09, 2004 6:27 pm

intel352 wrote:

isn't that similar to the sqllite database model? allows the programmer (in sqllite's case) to decide *what* he wants each sql field to be with no specific rules (that's the impression i get from the sqllite feature page)

Maybe, I don't know sqllite - I would have to check to give you an answer.

Quote:

i like your idea, that's something that could be applied to everything...

Exactly. That's the secret of SAP's success (besides being Open Source for ages before the term was coined - only for its customers, but still Open Source).

And that's the problem too: if you make it extremely flexible, the dreaded word will become "customization" instead of "coding". People will not realize its potential, simply because it is difficult to think of "adding the 'rank' field to the criterion object in order to specify sorting according to rank". The abstraction can become formidable, so formidable that people will prefer to make a "hack" instead of customizing 15 tables.

We must weigh the possibilities and choose a wise path. Flexible, but not too abstract. Then deliver a product that is "precustomized" for a number of standard "scenarios".

Chris

Posted: Tue Mar 09, 2004 6:45 pm

Ha I just wrote a long post that amounted to:

Quote:

chris:
We must weigh the possibilities and choose a wise path. Flexible, but not too abstract. Then deliver a product that is "precustomized" for a number of standard "scenarios".

Posted: Tue Mar 09, 2004 7:00 pm

Just dreaming here, but would it be possible in the forums, when someone posts a question, that it run against the keyword list? If the question matches a preset criteria based on the number of hits in the keyword list, instead of posting to the forum, a list of pertinet posts would be returned. That would force the user to take on some of the work that they expect the moderator to do for them. I think this may cut down on some of the overhead of answering repeatedly ask questions. From my visionary side, Steve

Posted: Tue Mar 09, 2004 7:12 pm

Sure! Some kind of "associative memory" a-la Amazon:

"Users who have used the keywords in your post (as determined automatically) have also posted in the following topics:..."

or:

"People who have read/written in this topic have also read/written the following ones:...."

or:

Raven's Top Ten List
Chris' Top Ten List

Oops...did I say Amazon? Could you guys start donating to the project? We need the money for the patent searches. Seriously. Shocked

Posted: Tue Mar 09, 2004 7:12 pm

That is the biggest negative with phpBB, sharlein, the search function is woeful and vary rarely produces the right answer(s).

Posted: Tue Mar 09, 2004 10:58 pm

Consider this for the configuration table concept. The table may or may not be named nuke_config. I have in mind an MCP (Master Control Program) type system. The site owner can name his tables whatever he wants and the system calls the configurator, if you will. That tells the MCP Object what the tables and possibly filenames are named. Then, the configuration is designed like PHPBB's config table. It is a setting and a value pair. That will allow for the flexible addition of addons, etc. An example as far as concept would be the issue today with adding a field to any of the tables, but let's use the author's table. You want to add a setting for ModuleX admin. Today you have to do a database expansion and then modify several sql calls. In my nirvana, you simply add a value pair to the table. Then you simply query the table to see if that value pair exists. See how easy that was? Taking it one step further, you want to try a new mainfile.php file (although conceptually that will be different but serves a purpose in discussion). Instead of renaming mainfile.php and then replacing it, you simply tell the MCP to crossreference mainfile.php with new_mainfile.php. See the difference? As much as possible, the system is table driven. Comments please. Remember that this is conceptual, not designed yet Smile

Posted: Wed Mar 10, 2004 12:15 am

What is MCP? Any link so I can get the idea? Or is it a theoretical concept?

Idea: the MCP writes a log file (or table) in man-and-machine-readable format (XML?) that stores all changes done since the delivered "pristine" state. If an update is installed, it looks at that file (or table) and at least tries to automatically run the changes documented in it.

I don't know if the newer configurators for the Linux Kernel use any such concept, but I always miss it whenever I have to compile a new kernel.

It's not CVS, but something close and more practical.

Posted: Wed Mar 10, 2004 1:39 am

Some positive feedback in this thread.
I would have to agree with Raven that the core code for any fork or indeed any other CMS/Portal option might have to be worked almost from scratch if need be - the obvious caveat being that there must be some upgrade or conversion path from a specific version of phpNuke to whatever the end result of this discussion gives us.
After all, whatever personal (or other) gripes we may have regarding the current phpNuke portal, it is phpNukes functionality, relative ease of use 'out of the box' and above all, its support in the way of add-on modules that has made it one of the most popular portals around.
So in short, it would have to utilise and build on, the exisitng nuke DB structure.

I think its great that people or using comparisons to other scripts, for noobs like me, this gives me a better understanding of what people are trying to say and a clear idea of the sort of functionality they deem as a 'requirement' for any criteria that might be passed on to the end product.

The vast number of CMS/Portal scripts that are currently in use have survived (well, most of them) for one simple reason - there is atleast one strong feature in that script that the users found indespensible, so it makes sense to take the best features around and combine them. By doing so we could get as close as we can to the 'all things to all people'.

Posted: Wed Mar 10, 2004 5:31 am

karakas wrote:

What is MCP? Any link so I can get the idea? Or is it a theoretical concept?

It's in my post, you just missed it in all my ramblings Smile

MCP = Master Control Program

Posted: Wed Mar 10, 2004 5:42 am

O.K., I didn't miss it, I simply thought it could be some notion that is described in some Computer Science book or something. I guess it is something like the "main loop" in other event-driven languages.

Posted: Wed Mar 10, 2004 5:52 am

That would be correct. Sorry for the miscue. BTW, I sent you a PM last night in case you didn't see it.

Posted: Wed Mar 10, 2004 7:41 am

Quote:

Taking it one step further, you want to try a new mainfile.php file (although conceptually that will be different but serves a purpose in discussion). Instead of renaming mainfile.php and then replacing it, you simply tell the MCP to crossreference mainfile.php with new_mainfile.php.

So if I understand this correctly;
The MCP will call and run the routines/functions etc in mainfile.php UNLESS an identically named named routine/function is called in new_mainfile.php in which case it only executes the one in new_mailfile.php ?

This reminds me of a useful feature in one of the Perl portals whereby all the main folders have secondary named folders and files.
i.e. if taking the phpNuke root file list as the base, there is an additional folder in root called USER which has a copy of all the other folders, when you call (for example)
http://www.yoursite.com/modules.php?name=Surveys
the MCP checks first to see if a file exists;
http://www.yoursite.com/USER/modules.php
and if it exists, it checks to see if the function ?name-Surveys exists, if it does it executes, if not, it executes the first one.

I think this would allow a much greater amount of flexibility, especially when testing hacks, or other code enhancements and modifications.

To take this concept further, core code files would naturally be stored in the normal folder list hierarchy with users modified files being stored in the duplicated folder list under the main folder USER.

Posted: Wed Mar 10, 2004 8:12 am

Exactly. But, the reason this MCP concept is needed is that PHP does not allow function reregistering (concept: overloading). I hotly contested this with the PHP development team, or actually one of its lead developers. Some of them can be quite sarcastic, to say the least Laughing

. Anyway, the simplest implementation would have been to load mainfile.php and then have a line at the bottom of mainfile.php that says (in pseudo code)

If USER/mainfile.php exists then load USER/mainfile.php and 'overload' like named functions.

However, PHP uses a multi-scan pass for interpreting/compiling. When mainfile.php is parsed, all of the functions are registered/declared first and cannot be reregistered/redeclared. PHP will croak if you try. That's why your code can refer to a function in PHP before it is declared. There is more than one way to implement this approach but it's the concept, right now, that I am proposing.

Posted: Wed Mar 10, 2004 8:44 am

As a concept, I think IMHO, that the way you propose is definitely a leap forward.

If nothing else, it has to be a fantastic time saver on development, hacks etc as the role-back could be so easy to accomplish (delete the appropriate file in USER/yourcode )

Taking the language files as one simple example - how many times have users forgotten about lang file modifications when installing core file updates?
I know I have, on many occassions!!

Posted: Wed Mar 10, 2004 8:51 am

It would make installs much easier too. There would/could be a standard installer for ALL. It's really a form of version control. The installer asks what your USER file is called, as you might use several for different purposes. Then, it attempts to install the files in like named directories. If a version already exists, you can be prompted to overwrite, rename/version it, or cancel. What could be easier? Rollbacks becaome automatic too.

Posted: Wed Mar 10, 2004 8:52 am

So if I'm not mistaken the biggest hang up now is how to implement this technique you've been working on without over using system resources. PHP's dev team is for the time being not willing foster this memory saving concept you pitched to them.

So back at the drawing board you are with plan B. Which amounts to creating a layer that will handle calls the way you originally proposed but without the added benefit of speed that php level handling would have brought?

Or did I miss the whole point?

Posted: Wed Mar 10, 2004 8:58 am

I have a way to do this but not that easily fits into the current nuke. I have accomplished it but it's a pain. All the more reason to start basically from scratch.

Posted: Wed Mar 10, 2004 9:52 am

You won't get any arguments from me over a 'from scratch' script, with the obvious caveat that it should offer an upgrade/conversion path for pre-exisitng nuke databases.

New Member Joined: Oct 22, 2003 Posts: 10

Raven,

As a relative noob, I mostly lurk around here benefiting from the wisdom and generosity of others. I have watched this thread with interest for several days now and figured I’d add my two cents as well.

I used to drive an ‘81 Honda Civic. I loved the car because I could do all the repairs, it was cheap to operate (I was a student) and it got me where I needed to go, just not in style. I hung on to that thing until it had close to half-a-million miles on it. When I sent it to the junkyard, it was still running. But it just wasn’t worth working on it anymore. The frame was bent, ball joints were loose, it had some body rust, etc. It just got to where I could do things better/faster/cheaper with a newer car.

While I’m NOT saying nuke is equivalent to a beat up crappy car that should be relegated to a cyber-junkyard, I do get the impression from other posts and from my own experience that it has some significant limitations at very fundamental levels. Maybe it’s time to focus all this immense talent on something new.

That said, I really hope you go forward with this project. I was skeptical at first, mostly because I dread the thought of committing to a specific CMS/portal, new or old, and then getting stranded because support for it never reaches critical mass and/or splinters off. For people like me, with only rudimentary coding skills, this is probably our biggest fear. And endless forks do have the potential to dilute the critical mass that a site like nukecops has been so successful at creating. But, as others have already pointed out, if one sticks with phpnuke simply because the project has inertia, the opportunity to innovate in a very meaningful way may be lost.

Of course there has to be an assessment of resources – enough programming talent, project management talent, etc – to ensure the success of the project from a structural and resource standpoint. But if that’s in place, and from the enthusiasm on this thread it sounds like it could be, then I feel like you have unlimited potential to produce something great. And “if you build it, they will come”.

I hear frequently that the power of open source efforts such as this lies in the potential for endless innovation, jus as this project could demonstrate. I think it would be real loss to not move forward.

Either way, I remain grateful for your efforts in whatever milieu you ultimately choose to contribute them.

Posted: Thu Mar 11, 2004 5:31 am

I want to thank everyone for their comments thus far. I am still 'counting the cost' of such an endeavor. While I am still not saying I am ready to start, I would like to get a little more specific on who and what. I basically see the following breakout:

1 - Architecture and Infastructure
2 - Core API Development
3 - Security
4 - Plugins
5 - GUI
6 - Themes
7 - Documentation
8 - Testing

I would like to attach some potential staff to each of these basic groups. This is not [yet] a committment; it's more a 'show of hands', if you will. You can place your name beside more than one group. If you do, please rank your desire/skill so I can better see how the team might look. What I mean by rank is not a skill level. I simply mean if you are willing to work in more than one area, what is your preference ranking, eg. 3 and 7 but prefer 3.

Once again, thanks so much for your interest in this!