The future of PBW - a call to arms

[farstryder]

While my programming skills aren't much to speak of, I'm quite decent at writing. If it would be necessary (or even merely desirable) to write up text for various aspects of the interface, I would be most pleased to help.

Its not much, but its what I have to offer for now.

As far as what language, in my experience, I've liked PHP best of any of the others I've seen. Not that I know much about it, but that's what I'd vote for.

[Gandalf Parker]

I wish I knew more about how SEIV does things before I posted this so pardon me. But I see 2 "paths" here that are often used in writing something like this.

A) programming from the top down. The menu choices are written, the sub-routines ironed out, often results in one huge program in one specific language, using the system to answer a need is the Last consideration

B) designed from bottom up, system answers are put in place first, then routines to access them, finally they are put together under menus

Both have their pros and cons. A big part of it is that "A" is easier maintained by programmers, and "B" is easier maintained by SysAdmins. Also "A" is easier for fansites to setup, and "B" has advantages on a dedicated server.

Im afraid that if I were to flow-chart/psuedo-code a project like this it would be in "B" mode due to my background (and even then I would be mostly in linux mode asking for help from the Windows admins here)

It seems as though the PBW we have now is "A" mode. Which is fine but the pros and cons of it is something we are running into now. Id love to see it fixed up and back running. But I have more interest in seeing a "B" mode done than in seeing a different "A" mode.

This post may be way out of line and maybe I should start a different thread to explain a "B" mode layout so people can tell me that SEIV wont work that way?

[ June 09, 2004, 16:18: Message edited by: Gandalf Parker ]

[Ragnarok]

If it is designed from the ground up using PHP and MySQL I can help out a little. I use those two combined for our website at work. While I cannot play a large part in the work due to no time it seems, perhaps when/if development does start I can take a look at the code and offer suggestions or help out with some small problems. It is not much but best I can do.

[Roanon]

Originally posted by Gandalf Parker:
This post may be way out of line and maybe I should start a different thread to explain a "B" mode layout so people can tell me that SEIV wont work that way?

Yes please.
I have been (also?) excluded from the exclusive tesco-picked circle of first-hand designers (I guess too much professional experience ) and don't know if I have made my point clear enough to whoever decides about PBW future that another system with the same eventually unmaintainable structure as the current system might not be desirable.

[tesco samoa]

I have not sent all the emails out yet.... I am at work and well work calls.... that stuff i do from home....

Originally posted by Gandalf Parker:

...

A) programming from the top down. The menu choices are written, the sub-routines ironed out, often results in one huge program in one specific language, using the system to answer a need is the Last consideration

B) designed from bottom up, system answers are put in place first, then routines to access them, finally they are put together under menus

...

I would have thought that B is the best model for anything that's going to be built by a distributed team. And if we're talking about project structure and development style, then I'd like us to aim at a sort of RAD style prototyping + incremental updates approach rather than specifying an all bells-and-whistles PBW and trying to build it in one big go.

and Roanon wrote...
Yes please.
I have been (also?) excluded from the exclusive tesco-picked circle of first-hand designers (I guess too much professional experience ) and don't know if I have made my point clear enough to whoever decides about PBW future that another system with the same eventually unmaintainable structure as the current system might not be desirable.

It would probably be good if we could avoid the paranoia and bickering quite this early in the project ...

Mark

[ June 09, 2004, 21:17: Message edited by: Mark the Merciful ]

[Ruatha]

Originally posted by Mark the Merciful:
I've just been reading the threads on the PBW emergency server (do a search on "emergency server" to find the relevant stuff). Question for everyone involved, especially Ruatha; is this ready to run should PBW die completely, and could it be a useful starting point for the new project?

Mark

It is an emergency system.
(And mostly untested, it's been tested mostly as a fileserver but should work also as a gameserver.
It can perhaps be set up to bear the load of the current PBW server, but not with the versatility that PBW has offered (Multitude of mods, exe Versions, files and forums, etc)
There is no password protection for regular Users, only for admins.

And no, it is not something to build a new PBW server on, it's an emergency thing.

A new PBW server should be built from scratch with no old code, only old ideas.

Before anything get's programmed it must be decided what should be programmed, a clear though through flow chart of everything.
Then it can be decided what should be made first.
That's my point of view but I have the utmost trust in that Tesco will do a good job.

(I've promised my wife that the companion is almost done, so I'm not in the situation of getting involved in a new project )

I have switched on the Emergency server now, mind you that it is on my home computer with my internet connection. So it's not too fast.
But as an example of what it can do: (The autoturn.exe isn't running.)
http://ruatha.homelinux.org

the software (Still under slooow development can be found here):
http://ruatha.homelinux.org/PBW_e2_beta.zip

If anyone want's to check the software out you will realise why it isn't something to build a new PBW server upon

[ June 09, 2004, 19:19: Message edited by: Ruatha ]