Insecurity? A SQLite database is ment to be written by clients... of course it is not like a server database, with users, privileges and so on. But it still does the job. We are talking about an AIR application that does not offer much functionality as much as some powerful desktop frameworks such .NET. But I like the idea to do with AIR things that cannot be done natively. It is a kind of self satisfaction and in some cases, loyality.
On Sun, Jan 11, 2009 at 12:13 AM, Anthony Pace <anthony.p...@utoronto.ca>wrote: > And did I mention unreliable? > > > Anthony Pace wrote: > >> Well of course you do, he seems to be backing up your bad method. And >> again... the DB in your scenario is a file on the network being written and >> over written by each client; thus, as I stated, very insecure. >> >> Omar Fouad wrote: >> >>> 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 >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> 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
