Dave, I was thinking the same thing. After reading through this thread again, I realized that this client to client thing can be handled using a simple server. And there are already many open-source solutions out there that will accomplish this behavior. Red5, WebORB and BlazeDS all support concurrent connections and passing data from client to client.
If you're already depending on the network for SQLite access, why not just host some server solution on said network? Cheers, Nate On Sat, Jan 10, 2009 at 9:44 PM, Dave Watts <dwa...@figleaf.com> wrote: > I apologize if I've missed something that anyone has posted in this thread. > > > 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. > > I don't think security is the main problem here, but rather the lack > of concurrency control. SQLite is meant to be a single-user database, > and has no multi-user concurrent capability. > > Since AIR can talk to remote web services, why not just set up an > application server somewhere and let your AIR apps talk to that? Let > your app server (and/or its backend database) handle concurrency > control for you. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction at our training centers in Washington DC, Atlanta, > Chicago, Baltimore, Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more information! > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- Cheers, Nate ---------------------------------------- http://blog.natebeck.net _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
