Hi Folks..
I am trying to create web3.0 forum software from scratch.
This forum will be heavily ajax driven and preferably require no
manual page-refreshes at all anymore.
And I will also use quite a lot of tree data structures in this
design. My subforum list and my thread->messages are both
tree-structures for instance (enabling nested replies to messages).
This has led me to think, it might be better to use a JSON storage for
my data, then store that on a RAMdisk on the server, instead of using
a SQL database.
For a forum, consider this basic data-struct example (under construction ;))
dataProtocols : {
user : {
userID : -1,
userTitle : '',
userLogin : '',
userGender : '', /* G=Group, M=Male, F=Female, T=Transsexual,
H=Hermaphrodite */
userFirstName : '',
userMiddleNames : '',
userSurname : '',
userMaidenName : '',
},
forum : {
forumID : -1,
forumName : '',
forumDescription : '',
subForums : [ /* forumID, forumID, ... */ ]
},
message : {
threadID : -1,
messageID : -1,
timeSent : null,
senders : [ /* userID, userID, ... */ ],
to: [/* userID, userID, ... */],
cc: [/* userID, userID, ... */],
subject : '',
body : '',
replies : [/* messageID, messageID, .... */]
},
thread : {
forumID : -1,
threadID : -1,
threadSubject : '',
threadOpeningMessageID : -1
}
}
and the actual in-browser javascript memory of the entire forum
content, would be, I think;
memory : {
users : [ /* userID, userID, ... */],
forums : [ /* forumID, forumID, ... */ ],
threads : [ /* threadID, threadID, ... */],
messages : [ /* messageID, messageID, ... */],
},
With JSON+RAMdisk storage, you could emulate shared memory on the PHP
server between all browsers connected to the site.
But the one thing that puzzles me is how to get changes made by one
browser to be displayed in all other browsers, efficiently and with
the least amount of collisions.
Obviously, an "event engine" is needed in both browser and server, and
perhaps it's best to maintain a flat list of changes made to the tree
data structures (by some browser(s)), then distribute that
changes-list to all open browsers. One could include timestamps to
make sure that no (partial) edits are made on data that has recently
been updated (this update would be transmitted to the browser editing
the same field and the user would be presented the option to
abort/update his/her own edit).
The alternative would be to spend A LOT of time building the required
SQL datastructures and PHP libraries to manipulate that SQL. I'm
really thinking it would be much simpler to just stick to JSON stored
on a RAMdisk.
I have found http://memory.dataram.com/products-and-services/software/ramdisk
to work well in conjunction with my http://www.wampserver.com/en/
This RAMdisk software is free for personal (or testing) use, and can
create RAMdisks for free of up to 500gb, and, more important, can on a
regular time interval auto-save the RAMdisk content to
(truecrypt.org-ed :) harddisk storage, plus load the RAMdisk from
harddisk storage after a reboot of course.
A forum could also use a media storage plugin, and photos and any
uploaded videos you'd just store on and read from regular harddisks of
course.
But the actual forum content, is all (html) text, and quite short usually..
So I'm guessing that with a 500mb RAMdisk, you could keep the entire
forum content for quite a large forum in RAM, and thus serve it at
lightning speed.
Now, what I'm not so sure about, is how to efficiently get changes
made to the super-global datastructure by one browser, distributed to
all other browsers in such a way that the least collisions of edits
occur. Ofcourse, adding a reply to some post on the forum would not
cause much of a problem (with other replies to the same message coming
in while the user's editing his/her reply), but for instance adding a
reply-with-quote while the original owner of the message replied to
edits his/her post, would require the person replying to be notified
(in an eye-candy-rich way ofcourse;) that the message he's/she's
replying to has changed (and preferably highlighting the change). And
I'd love some tips on how to make that last scenario easy to handle in
code.
I seem to have figured most of this out, but before I embark on weeks
of coding, I'd like to give the SQL experts here a chance to convince
me to stick to MySQL for my data storage and distribution needs. I'd
love to hear of a simple way to efficiently store and operate a forum
with tree-structures for both subforums and threads->messages using
MySQL, as my live hoster does not support RAMdisks, not without
charging me about 70 euro per month instead of the $7 I pay now ;)
Ok, thanks for reading and possibly considering all this,
Rene
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
