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 <[email protected]>: > > 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 < >> [email protected]> 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 <[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 >>> >>> >>> >> >> >> >> >> > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
