Yes Pablo, that is an issue that I am being thinking about today. I want to
enable user presence detection to the client.
I've been thinking to let each client logged to the chat, send it's "id" to
a table called ActiveUsers. When the user Closes the Application, the row is
deleted. At the same time, the application intervally queries the table to
see what users are online. This is a good Idea, but there is a problem. What
if the connection is cut, or the application is closed by an "end task"
command or by the system? How would I update the table and delete the user
from it?



On Sat, Jan 10, 2009 at 2:40 PM, Juan Pablo Califano <
califa010.flashcod...@gmail.com> wrote:

> 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
>



-- 
Omar M. Fouad - ActionScript Developer
www.omar-fouad.net
Cellular: (+20) 1011.88.534
Mail: m...@omar-fouad.net

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to