Page 1 of 2

Posted: Wed Nov 28, 2001 7:34 pm
by psoTFX
Jay ... hint ... I created a new forum for devs to discuss issues without everyone else wanting to have their say too :)

Posted: Wed Nov 28, 2001 7:41 pm
by Jay
i didn't even notice the new forum.. i have the phpBB Portal forum book marked.. :D

Posted: Wed Nov 28, 2001 10:50 pm
by The Que
:D hehe to keep people like me out.

Seriously though that's a good idea and a good move.

Cheers!

Posted: Wed Nov 28, 2001 10:58 pm
by BartVB
Hmm, keeping people out sounds a bit harsh..

I would EXTREMELY welcome it if people would discuss the development matters in here too. The separate forum is mainly there to keep things structured and on topic..

I hope that a lot of the work will happen in here..

Posted: Wed Nov 28, 2001 11:01 pm
by dhn
Yeah, but as you have seen in the past few weeks things were rather confusing here (at least I had problems to keep up with all the stuff said). I think it is important to have a place to structure everything. People can still comment (as they can read the portal development forum) and add suggestions over here.

Portal Structure Suggestions

Posted: Thu Nov 29, 2001 5:56 am
by Faejon
I like the way the discussion is going in the Developer's Lounge. If I may let me throw my 2 cents into this discussion. If you break down the portal into several parts say; Core/Global, Module/Limited Scope, and Add-On/Global.

Features in each:
Core - Functions necessary in all parts of the website. Variables with global scope.
  • Registration
  • Authentication
  • User Profile / Preferences
  • Whos Online
  • Private Messages
  • Error Detection and Notices
  • Core Language Files (more on this later)
  • Core Administration
  • User / Groups Administration
  • Message Posting Function
  • Word Censor
Module - Functions created for a specific module. Variables have limited scope to just within the module pages.
  • Module Specific Language Files
  • Module Specific Administration Functions
  • Module Rules for handling inherited core variables and data
  • Module functions
Add-On - Functions which expand the core features. Variables with global scope.
  • Add-on Specific Language Files
  • Add-on Specific Administration Functions
  • Add-on Rules and interface for handling function calls from unknown modules (basically add-ons are black boxes)
As I see it the task for the portal developers is to create a set of rules by which modules and add-ons will be written uniformly. The portal would then be able to either automatically detect (checking a folder for new files with a .mod extension or something) or provide an interface by which the website administrator could pick and choose which add-ons or modules were active.

The next logical step would be to read the .mod file (I was thinking of something similar to the way a Makefile works) and cache the data, store it in a db or read the file each time (I see a major performance hit here). The .mod file would basically be a collection of variables to be initialized, file paths and setup information. A companion to the .mod file would be a .sql file. This file would contain the needed database additions. The .sql file would be processed by the core and internally logged that the changes were made.

This is all theory at this point and I have no code to back it up yet. I just put this out here to help you get your creative juices flowing.

Posted: Sat Dec 01, 2001 2:12 am
by scotshin7
I think it should work this way -
  • Core
    • The I/O for modules, e.g. to exchange information by themselves and get GET/POST vars, etc.
  • Modules
    • Registration
    • Authentication
    • User Profile / Preferences
    • Who's online
    • Private messages
    • Error notices
    • Administration
    • Message posting
    • Word censor
    • Each module's going to have some standard functions, e.g. info() which will identify itself, et cetera
So my system is completely module based, and the core is only the handling of the modules...
Just my $0.02...

:mrgreen:
[edit]
psoTFX wrote: ...forum for devs to discuss issues...

Excuse me, but does that mean that dev members are frozen?
[/edit]

Posted: Sat Dec 01, 2001 2:16 am
by psoTFX
Okay, let me try saying it this way ;) We aren't going to turn phpBB 2 into a module to suit the portal ... there, did that come across any better? :D

As for 'dev members', that's up to Bart (as Lead) and James (as Manager) ... Bart has already said that for now he thinks they've probably got enough people to 'get going' but more would be recruited as development gets started.

Posted: Sat Dec 01, 2001 2:20 am
by scotshin7
Then how about a module API to access some phpBB functionality?
e.g.,
Module A wishes to use auth(), and calles Module B
Module B handles the request, calling auth() directly
Module B returns the results

It'll flow better if phpBB's functionality was a module, but that's not possible, so this method may be better...

Posted: Sat Dec 01, 2001 7:06 pm
by Jay
scotshin7 wrote: I think it should work this way -
  • Core
    • The I/O for modules, e.g. to exchange information by themselves and get GET/POST vars, etc.
  • Modules
    • Registration
    • Authentication
    • User Profile / Preferences
    • Who's online
    • Private messages
    • Error notices
    • Administration
    • Message posting
    • Word censor
    • Each module's going to have some standard functions, e.g. info() which will identify itself, et cetera

isn't most of that stuff already in phpBB2?

Posted: Sat Dec 01, 2001 7:07 pm
by scotshin7
Hmm, how about making an API for modules to access those things that are already in phpBB and are usable, and make that API directly call those functions?

Posted: Sat Dec 01, 2001 7:10 pm
by Jay
scotshin7 wrote: Hmm, how about making an API for modules to access those things that are already in phpBB and are usable, and make that API directly call those functions?

I'm pretty sure that's what we want to do.. we don't want to have to rewrite code that is already written.. hence the reason we are using phpBB 2 :D

Posted: Sat Dec 01, 2001 7:20 pm
by scotshin7
As in the API is another module... IMO it should work something like this...
Module A wants to use auth(), and through the module system, accesses Module B(the API) and tells it that it wants to use auth() and wants these parameters passed.
Module B directly accesses auth() and returns the results to Module A.

Posted: Sat Dec 01, 2001 7:53 pm
by Kanuck
Whoa, deja-vu... ;)

Anyways, the entire system will be module-based. Things like the authentication system, the user profile system, and phpBB itself will be treated as modules. Obviously, they won't actually be modules; the phpBB coding will be very deeply integrated into the project, it will only be treated as a "module" on the surface, for the sake of simplicity.

We're still discussing how exactly we're going to do things like this, we've got lots of ideas kicking around in the dev lounge, but nothing's been nailed down yet.

Posted: Sat Dec 01, 2001 8:57 pm
by scotshin7
Kanuck wrote: Whoa, deja-vu... ;)

Hmm, why? [edit]Whoops, forgot that I had already described it...[/edit]
Kanuck wrote: Anyways, the entire system will be module-based. Things like the authentication system, the user profile system, and phpBB itself will be treated as modules. Obviously, they won't actually be modules; the phpBB coding will be very deeply integrated into the project, it will only be treated as a "module" on the surface, for the sake of simplicity.

That's what I was thinking too actually, phpBB/all its other stuff should look like a module to other modules, but it shouldn't to phpBB/all its other stuff themselves...
Kanuck wrote: We're still discussing how exactly we're going to do things like this, we've got lots of ideas kicking around in the dev lounge, but nothing's been nailed down yet.

Is it okay if the community could contribute in that discussion? I'm not saying that forum should be open, but the community should make an influence...