Yeah Juan I agree with you. On Sat, Jan 10, 2009 at 11:58 PM, Juan Pablo Califano < califa010.flashcod...@gmail.com> wrote:
> Anthony, I'm curious as to why you consider using a raw file any better > than > using the SQLite engine (which uses a single file as a datastore, yes, but > provides a higher level and way easier access to the data). > > The client has indeed a lot of responsibility, but isn't it the same (or > perhaps even worse) if you use bare files on a network share? The client > talks directly with the data base and in a web app, this would be a very > bad > decision. But given that this would be deployed in a LAN, as an Air app > (which natively supports connecting to a SQLite database), I'd say it's > probably not that bad, all in all. > > Cheers > Juan Pablo Califano > > 2009/1/10, Anthony Pace <anthony.p...@utoronto.ca>: > > > > This is just a bad way to do this. The client becomes responsible for > > everything, and that leads to security issues like crazy. > > > > If this is for professional use, as you have stated multiple times, I > would > > say find a better way. > > > > Write delay based on file stamping, with all the clients agreeing to work > > based on the same parameters, is the only way to make this work even > > marginally well in a production environment. > > > > If file has an id and range of time associated to it that has not lapsed, > > and my id is not the same, I cannot write. > > > > > > Omar Fouad wrote: > > > >> 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/> <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/> <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 > >>> > >>> > >>> > >> > >> > >> > >> > >> > > > > _______________________________________________ > > Flashcoders mailing list > > Flashcoders@chattyfig.figleaf.com > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > 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
