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 <anthony.p...@utoronto.ca>: - 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
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
