views:

60

answers:

4

OK Ive written this neat javascript 'thing' using jquery and ajax. Its all based on the idea that a div has an attribute that lets you write inside the div. (contenteditable=true). I thought it would be cool to make a chatroom type thing out of it, and holy cow its doing some cool stuff(*), but I have an issue.

Using ajax I post to a php page that takes the posted data (x,y, text, id) and stuffs it into a JSON-like object. Without writing to a database (overkill I think), how can I make this data persist? See the problem? : The variables in a php page are essentially vapor after the page has ran, so my javascript ajax call to retrieveNewJSON() would find nothing.

*using jquery effects and setting colors I have variably placed text that scrolls and evaporates, matrix style, for example. Also, a cursor is placed in the div where the user clicks.

A: 

You have to store the data somewhere. If you don't want to use a full blown database you can store them in flat files (ie: txt) and use PHP's file functions to handle the files.

Of course this is not very scalable, and I'd strongly recommend using a database if you are going to be using this a lot.

NullUserException
File storage would be very costly. That is a bad option.
Josh K
@Josh You don't even know what he is going to use if for, how do you know it "would be very costly?" Besides, I said this is not very scalable.
NullUserException
@NullUser: Costly in terms of overhead. I wouldn't say this could support any number of real users efficiently. Not to mention they could use this to write data to the server if not handled properly. Overall this is a hard to implement, completely un-scalable, and inefficient attempt to replicate what you should be using, which is a session.
Josh K
'cept session data is private (I believe...) and having everyone keep a private variable thats a copy of everyone elses private variable sounds inefficient as well, not to mention therell prolly be syncing issues.
jason
@Josh Read the question. You can't implement what he wants with sessions, period.
NullUserException
@NullU: If you update each users `$_SESSION` from something else you can. However in this case I don't believe either solution is best.
Josh K
@Josh Of course not. That's why we have databases.
NullUserException
@NullUser: Which is why you would consider using file storage? That is the worst alternative to a DB I've heard of.
Josh K
@Josh That's absolutely incorrect. That's the most natural alternative to a DB. After all, DB's store their data in... huh, files.
NullUserException
@NullU: Flat files are not comparable to a DB. It doesn't matter where they end up being stored, a database has faster access to the data you need with less overhead then implementing a file based storage system.
Josh K
@Josh That's also incorrect. Depending on what you need to store, databases have *more* overhead than a file based storage system.
NullUserException
@Josh That's actually a really baseless statement. Using PHP with a MySQL database means you have to: (1) run an additional process (MySQL) (2) open a connection to the MySQL server, even if PHP and MySQL are running on the same machine. Not to mention all the abstraction needed to make this work properly and cleanly (an ORM, a DBAL, etc.). That's **way more** overhead than a flatfile. Do you even know what "overhead" means?
NullUserException
Case in point: [implement this](http://left4churr.com/login/) using a db and tell me it's got less overhead.
NullUserException
@Null: Less transactional overhead, I'm not talking about how many lines of code you can write it in. That would be trivial to implement in a db, not to mention easier to manage. Check your file size.
Josh K
@Josh There, fixed. Try and run your script again.
NullUserException
@NullU: I don't recall MySQL (or any other database) imposing a 5k record limit before it tanks. You still going to cling to a file based system? What happens when more then a handful of people are using it? I *especially* like how your "db" shits itself every so often. Would that be a good idea for a login system? To periodically "forget" users?
Josh K
@Josh 5k is a pretty comfortable limit. It will yield a file size of only ~326 KB, and it can go way beyond that. It has its flaws because I coded it in 10 minutes.
NullUserException
I am not the one clinging to something. I acknowledged that a flatfile has its problems with scalability compared to a real DB (read my answer ^), but they are still usable and have their applications. You are the one with the "flatfiles are evil" mantra.
NullUserException
@NullU: They are vulnerable. Without lot of information about the system he needs you *can't* in good faith recommend it.
Josh K
@Josh He asked specifically: "Without writing to a database (overkill I think), how can I make this data persist?" And Sessions won't work in this case, so flat files are a viable solution.
NullUserException
A: 

You could use a the $_SESSION variable to persist data.

// Call at start of PHP script
session_start()
//....
// Store object
$_SESSION['obj'] = json_encode(obj);

in your pull script:

// Call at start of PHP script
session_start()
// Retrieve object 
echo $_SESSION['obj'];

Note that when using sessions you have to make sure that you call session_start() at the top of every php script that uses the session.

I would not recommend trying to store this in a file unless you are supporting a very low number of users and have taken proper data sanitation steps to physically write files to the server. If you need this to persist past the length of a session you should be using a database.

It is worth noting that you can't update a users session without some other form of centralized storage. Unless you have some sort of long-polling / comet type setup you will have to have some sort of central storage place. Something I would take a look at would be memcache.

Josh K
I don't understand the downvote on this one. The user's session is *the perfect place* to store *temporary* data. On the other hand, permanent storage would require something better. Like, oh, say, a database.
Charles
(1) Sessions are not persistent. (2) You can't access another user's session, making it impossible to implement a chatroom. Read the question.
NullUserException
(1) Never said it had to be persistant, (2) why would you need to access another users session? How would writing this out to a file solve *any* of the issues presented?
Josh K
So in the chatrooms you visit you are just talking to yourself?
NullUserException
@NullUser: He said chatroom type thing. We don't have a ton of data to go on.
Josh K
A: 

You could use cookies (client-side) or session variables (server-side), or you could write to a file for longer-term storage.

Brian Driscoll
A: 

If you want to avoid using a database engine (which would have a lot of overhead for a multiple-read, multiple-write app like a chat room anyway), you might look at a simple object store like memcache, couch, or mongo. Files are also a valid option, provided you store them outside of the Web root with proper permissions. Bottom line is, you'll have to use some sort of storage engine on the back end in order to make the data shareable across multiple user sessions.

If this is simply a tech demo or a proof of concept, I wouldn't worry too much about overhead right away.

Ryan Chouinard