1

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.

jason
  • 4,721
  • 8
  • 37
  • 45
  • Yeah I thought about cookies, file storage, session variables. The trouble with cookies and session variables : Theyre not shared among the users. Say 2 people are typing in. They need a common place to push the data to. So that would have to be something sharable between them. The file idea is probably the way Im gonna have to do this I guess. I was hoping for some magic "heres an obscure function built into php that lets you persist a global variable" answer lol. – jason Aug 03 '10 at 18:36
  • That's what databases are there for. If you don't like MySQL, you can try SQLite – NullUserException Aug 03 '10 at 18:39
  • See my answer. You can use an in memory database instead of implementing a fullblown MySQL / SQLite db. – Josh K Aug 03 '10 at 18:44

4 Answers4

0

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
  • 83,810
  • 28
  • 209
  • 234
  • File storage would be very costly. That is a bad option. – Josh K Aug 03 '10 at 18:30
  • @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 Aug 03 '10 at 18:34
  • 1
    @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 Aug 03 '10 at 18:36
  • '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 Aug 03 '10 at 18:39
  • @Josh Read the question. You can't implement what he wants with sessions, period. – NullUserException Aug 03 '10 at 18:39
  • @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 Aug 03 '10 at 18:41
  • @NullUser: Which is why you would consider using file storage? That is the worst alternative to a DB I've heard of. – Josh K Aug 03 '10 at 20:04
  • @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 Aug 03 '10 at 20:19
  • @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 Aug 03 '10 at 20:35
  • @Josh That's also incorrect. Depending on what you need to store, databases have *more* overhead than a file based storage system. – NullUserException Aug 03 '10 at 21:59
  • @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 Aug 04 '10 at 14:07
  • Case in point: [implement this](http://left4churr.com/login/) using a db and tell me it's got less overhead. – NullUserException Aug 04 '10 at 14:08
  • @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 Aug 04 '10 at 15:45
  • @Josh There, fixed. Try and run your script again. – NullUserException Aug 04 '10 at 16:25
  • @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 Aug 04 '10 at 16:39
  • @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 Aug 04 '10 at 16:55
  • 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 Aug 04 '10 at 16:58
  • @NullU: They are vulnerable. Without lot of information about the system he needs you *can't* in good faith recommend it. – Josh K Aug 04 '10 at 17:04
  • @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 Aug 04 '10 at 17:08
0

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
  • 28,364
  • 20
  • 86
  • 132
  • 1
    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 Aug 03 '10 at 18:37
  • (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 Aug 03 '10 at 18:37
  • (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 Aug 03 '10 at 18:40
  • So in the chatrooms you visit you are just talking to yourself? – NullUserException Aug 03 '10 at 18:47
  • @NullUser: He said chatroom type thing. We don't have a ton of data to go on. – Josh K Aug 03 '10 at 20:03
0

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

Brian Driscoll
  • 19,373
  • 3
  • 46
  • 65
0

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
  • 2,076
  • 16
  • 11