[EMAIL PROTECTED] Wed Apr 07 11:31:42 2004 Return-Path: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] X-Apparently-To: [email protected] Received: (qmail 29686 invoked from network); 7 Apr 2004 18:31:41 -0000 Received: from unknown (66.218.66.166) by m20.grp.scd.yahoo.com with QMQP; 7 Apr 2004 18:31:41 -0000 Received: from unknown (HELO n17.grp.scd.yahoo.com) (66.218.66.72) by mta5.grp.scd.yahoo.com with SMTP; 7 Apr 2004 18:31:41 -0000 Received: from [66.218.67.175] by n17.grp.scd.yahoo.com with NNFMP; 07 Apr 2004 18:31:11 -0000 Date: Wed, 07 Apr 2004 18:31:11 -0000 To: [email protected] Message-ID: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> User-Agent: eGroups-EW/0.82 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 6700 X-Mailer: Yahoo Groups Message Poster X-eGroups-Remote-IP: 66.218.66.72 From: "psneville" <[EMAIL PROTECTED]> X-Originating-IP: 216.104.211.5 Subject: Re: Flex Needs Remote Shared Objects! X-Yahoo-Group-Post: member; u=69206070 X-Yahoo-Profile: psneville
Hi, We're thinking the ultimate solution needs to be more robust than one that relies on the server to hold connections, regardless of whether the client receives callbacks properly or not. A client polling mechanism is not as strong as one that allows the server to initiate messages directly to addressable clients, which would be possible with a more full-featured messaging infrastructure. This is something we're looking at for future development. Distributed synchronized data graphs are important to us, and while I'm not convinced that remote shared objects as-is today provides either the "right" API or the "right" message format/protocol/plumbing for this sort of thing in Flex, the general functionality of it is something that's certainly important and it is a useful benchmark. Too, as far as HTTP tunneling goes for real time messaging, we're also learning a lot from the experiences of the FCS team, and that knowledge is useful and directly relevant to Flex as a distinct, separate topic from remote shared objects. Thanks, Sean --- In [email protected], "Cortlandt Winters" <[EMAIL PROTECTED]> wrote: > Hi Alex, > > I was thinking this as well, but what about connection time outs, which > would make this method more of like a long-pause polling timer? I know that > there are both server and client level ways to mark the connection not to > time out with headers, but does that work reliably with flash in the various > browsers? > > If so then it seems like you are right that that this might be the best way > to go. I had been thinking that a socket server would be the way to go for > these kinds of things. Does anybody have insight into the pros and cons of > using the http stream vs socket methods? > > One pro that I can think of with the http streaming over socket connections > or remote shared objects is the issue of properly closing connections. For > example, I'm not really sure that when a browser is closed, that flash > always gets notified and is given a chance to close the connection properly, > possibly resulting in a browser crash with the binary methods. In the http > streaming method it seems like a poorly closed connection wouldn't be nearly > as likely to crash the browser, if ever. (In a rare case that's probably > still worth mentioning, someone's modem will sometimes trigger the > connection timeout rather than the browser, client or server and I'm not > sure if the browsers even get notified then) > > I haven't responded to this discussion before as it seems to me that remote > shared objects, as awesome as they are for flash developers, seem more of a > convienience method for flash developers than something that enterprise > developers would be interested in. After all isn't the whole point of most > of the J2EE architecture to provide enterprise level persistence across > servers? I think that remote shared objects would need more work to relate > properly to these other mechanisms. Certainly there are about a billion > java-based persistence mechanisms now. I could see shared objects as a > convienient caching mechanism though. > > Just my thoughts. > > -Cort > > -----Original Message----- > From: aglosband [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 10:33 AM > To: [email protected] > Subject: [flexcoders] Re: Flex Needs Remote Shared Objects! > > > I think this would be pretty easy to implement using HTTP Streaming. > Basically, the client makes an HTTP request to the server and the > server holds the connection open until there is data to push down to > the client. I believe this is the way some instant messaging > applications work and solves the problem of having to deal with > firewall issues. Here's a javaworld article that shows how to do this > with DHTML and servlets: http://www.javaworld.com/javaworld/jw-03- > 2000/jw-03-pushlet_p.html > > -Alex > > --- In [email protected], "Stacy Young" <[EMAIL PROTECTED]> > wrote: > > Maybe flex can generic "messaging" API via web service or something. > > That way implementations would be same across Java/CF/.NET > > > > > > > > -S > > > > > > > > _____ > > > > From: Dimitrios Gianninas > > Sent: Monday, April 05, 2004 5:17 PM > > To: [email protected] > > Subject: RE: [flexcoders] Flex Needs Remote Shared Objects! > > > > > > > > And of course this will have to be tied to the middleware somehow, > > especially for point 3 of Stacy's email. So it would have to be a > Java > > push? hmm.. don't know. > > > > > > > > Maybe Flex handles doing the push, but gets data from some service > and > > then sends it to all the client UIs. > > > > > > > > Jimmy Gianninas - Software Developer > > > > Terra Payments Inc. > > > > (514) 380 - 2700 extension 3249 > > > > > > > > > > > > <table width=800 cellpadding=4 cellspacing=10 border=0><tr > bgcolor=BDBDBD><td valign=top width=400><font face=verdana size=2 > color=FFFFFF><b>AVIS IMPORTANT</b></font></td><td valign=top > width=400><font face=verdana size=2 > color=FFFFFF><b>WARNING</b></font></td></tr><tr><td valign=top > width=400><p align=justify><font face=verdana size=1 color=808080> > Les informations contenues dans le present document et ses pieces > jointes sont strictement confidentielles et reservees a l'usage de la > (des) personne(s) a qui il est adresse. Si vous n'etes pas le > destinataire, soyez avise que toute divulgation, distribution, copie, > ou autre utilisation de ces informations est strictement prohibee. Si > vous avez recu ce document par erreur, veuillez s'il vous plait > communiquer immediatement avec l'expediteur et detruire ce document > sans en faire de copie sous quelque forme.</td><td valign=top > width=400><p align=justify><font face=verdana size=1 color=808080> > The information contained in this document and attachments is > confidential and intended only for the person(s) named above. If you > are not the intended recipient you are hereby notified that any > disclosure, copying, distribution, or any other use of the > information is strictly prohibited. If you have received this > document by mistake, please notify the sender immediately and destroy > this document and attachments without making any copy of any > kind.</td></tr></table> > > > > ------------------------------------------------------------------- --------- > ---- > Yahoo! Groups Links > > a.. To visit your group on the web, go to: > http://groups.yahoo.com/group/flexcoders/ > > b.. To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
