I think you could do take the same approach as in an "http" chat system (i.e., not a real chat solution but I've seen it used when data push from the server was not available thru FMS, Red5 or other)
You have at a minumun 2 tables: users and messages. When the user logs in, it's inserted into the users table and an id (such as an autoincremental) is returned for using in further requests. In the messages table you have these fields: messageID senderID recipientID delivered. Have each client polling the DD.BB <http://dd.bb/> at a regular (and reasonable interval) to get a list of available users (you can pass the data you need here, but the only realy necessary part is the userID). Each time a client polls the DD.BB <http://dd.bb/>. it also asks for pending messages (which could be a text message or whatever you need; not sure if SQLite supports BLOB fields, but if it does you could store serialized AS objects, I guess). A pending message is just any message that has the user's userID and the delivered flag set to 0. If there's any matching that criteria, return it to the user. When a client wants to send a message, it does an insert in the messages tables, passing the recipient userID (which you can grab from the users list you already have), it's own ID and a message. You could also put a timestamp in each record (both in users and messages tables) an every time a user logs in, delete any record whose timestamp is >= 24 hs old. For many scenarios, this would a problematic approach (you don't have a central server managing users interation, too much resposibility on the client, etc), but under the circumstances, I think it should work fine. Cheers Juan Pablo Califano 2009/1/10, Anthony Pace <[email protected]>: - Ocultar texto citado - > If you have ever run into problems when writing a file on the network when > someone else is trying you will know what I mean, and now just imagine that > you have an app requesting a write multiple times per second... there is no > reliance. > > Nifty solution for the short term; yet, not something that can be used > reliably. > > I might be wrong; yet, I doubt it. > > scenario 1... user1 opens the db file to put in their message; yet, user 2 > opened the file for writing just a milisecond before me, but it took your > request for a write longer to reach the file server than mine did > > this would result in user1's message being overwritten _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
