fpgroups.com: A raw chat room is now available

[fp at casabellagallery.com]

Mark posted:

[snip]

> "Do you want polite, or do you want sincere?"  --Unknown 
> 

Sincere is good, I do not have a problem with being sincere.

> > As per privacy, what privacy?  It is an open chat room.  If you want to
> > have a private conversation, pick up he phone or meet at your local park.
> > The site itself is meant to be a communal site, not meant for two people
> > to lock themselves in a private chat room.  That in itself goes against
> > the very principal I am trying to work on "unity" and "openly share" with
> > all.
> 
> When someone starts spouting incorrect answers to things and you want to
> correct someone else's impression of how it works without getting into a
> public pissing contest over it, you'll appreciate the need for /msg.
> Amongst other reasons.  Let's see...exchanging phone numbers or email
> addresses in private, talking about sensitive or confidential data with
> someone that's there but not wanting anyone else to see it--just the person
> you trust.  There are a slew of reasons.
> 

When you enter a "free" and "public" area, you loose the right of expectation
of privacy.  While I agree with some of your points, making sure people do not
see what you say, how you say it and providing you exclusive messaging really
does not fall into my "MUST HAVE" list.  It might be nice, but not a must have!


> > As per the error, I visit some of the web's most famous sites and I get
> > them there too ... and they have $$$$$$$$$ (those are Billions) to fund
> > these sites.  
> 
> Like the $1.7 YouTube, whose comment reply system has been hosed for over a
> week now?  Who can't even afford a simple status indicator when doing AJAX
> calls for ratings or comment submission?  Yeah, I know about some of these
> places.  What is -really- ironic are the number of places selling web
> design and programming services whose own sites generate errors.  :)
> 

Ouch, give the referee a pair of glasses, he sure should had seen that low-blow!


> Just because the rest of the world has more resources and can get away with
> doing it wrong is no justification for not getting it right yourself.

Did not try to justify lacking on some things, simply attempted to bring to light
that it happens.

> That's where places like Serif and CoffeeCup excel--they nail details the
> giants like Adobe totally let slide to the side.
> 

You keep on leaving filePro out of your applications list ... 


> > Following your advise, I will move forward, modify it slowly and steadily
> > and hopefully, it will grow to a fully functional, lovable, fast,
> > friendly and very popular chat room.
> 
> If you have a prioritised list, the first thing on it should be instating
> a keyboard re-focus to the textarea right after a message has been sent by
> the interface (as opposed to anyone having sent one--I'm talking about the
> user clicking on or hitting enter on the send button, which is actually two
> events to trap...I'd personally stick it in the beginning of the AJAX that
> does the actual submission).
> 

Noted!

> Speaking of which, I just had a thought, but I didn't test it.  Did you
> handle the case of multiple submission?  I just tried testing, but it won't
> even post.  I keep getting "problem saving chat data".  I'll assume you're
> working on it.
> 
> Okay, screw testing.  I'm -looking- at the code, and I guarantee you that
> the way it's written right now is wrong.  The AJAX has no limiting factor
> to prevent a race condition.  I'm imfamous for sending multiple short
> lines of text, sometimes as afterthoughts.  Your code would basically use
> the "xo" variable for the request.  However, on subsequent submissions, if
> another was asynchronously in use, the active request will be overwritten
> and will basically be "interrupted" and will not finish or trigger a
> callback.  Think of it this way:
> 
> xo - Send #1
> xo - Send #2 before #1 is finished.  Oops, overwrote xo object/callback/status.
> xo - Send #3 before #2 is finished.  Oops, overwrote xo object/callback/status.
> xo - Send #4 before #3 is finished.  Oops, overwrote xo object/callback/status.
> xo - Send #5 before #3 is finished.  I happen to be last in line, so I'm
> the only one of five messages that is actually fully acted upon properly.
> 
> You need to disable the submission functionality on starting the process of
> submission, and clear the status and re-enable it when the callback is
> triggered and processed.
> 
> Since I'm looking at the code, your comment about writing the code,
> etc., falls rather flat as an argument unless "Jose Lerebours" somehow
> translates to "@author JPA".  Strangely, I see no L in there for Lerebours.
> 

The JS script was written by a friend.  I mentioned this to Orlando last night
in the chat room.  I have nothing to hide.  The fact that you were able to 
download the file in question proves that.  I asked him for a little help and I
asked him to not "spoon feed" me the entire solution, just to get me in the right
direction ... and so he did ... In fact, he also helped me with PHP since I normally
do not use some of the things he suggested I use.  Had you given me a hand and put
your name within the sessions of code where you helped, I would have not removed it.

Again, if this was something alarming to me, I could have easily removed his initials
and place my own - Doing that, would have been totally out of character with me.

Regards,


---
Jose Lerebours
954  559  7186
http://www.fpgroups.com