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
