[EMAIL PROTECTED] Wed Apr 07 10:19:30 2004 Return-Path: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] X-Apparently-To: [email protected] Received: (qmail 97802 invoked from network); 7 Apr 2004 17:19:29 -0000 Received: from unknown (66.218.66.167) by m15.grp.scd.yahoo.com with QMQP; 7 Apr 2004 17:19:29 -0000 Received: from unknown (HELO hoggle.dreamhost.com) (66.33.197.5) by mta6.grp.scd.yahoo.com with SMTP; 7 Apr 2004 17:19:29 -0000 Received: from ZANEGORT (alb-24-195-30-213.nycap.rr.com [24.195.30.213]) by hoggle.dreamhost.com (Postfix) with ESMTP id 9954853869 for <[email protected]>; Wed, 7 Apr 2004 10:19:27 -0700 (PDT) To: <[email protected]> Date: Wed, 7 Apr 2004 13:12:16 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C41CA1.F33CB190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <[EMAIL PROTECTED]> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: Normal X-eGroups-Remote-IP: 66.33.197.5 From: "Cortlandt Winters" <[EMAIL PROTECTED]> Reply-To: <[EMAIL PROTECTED]> Subject: RE: [flexcoders] Re: Flex Needs Remote Shared Objects! X-Yahoo-Group-Post: member; u=121477995 X-Yahoo-Profile: cortlandt_winters
------=_NextPart_000_0002_01C41CA1.F33CB190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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. ------=_NextPart_000_0002_01C41CA1.F33CB190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"= > <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff si= ze=3D2>Hi=20 Alex,</FONT></SPAN></DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff si= ze=3D2>I was=20 thinking this as well, but what about connection time outs, which woul= d=20 make this method more of like a long-pause polling timer? </FONT></SPAN><SP= AN=20 class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff size=3D2>I kn= ow that there=20 are both server and client level ways to mark the connection not to ti= me=20 out with headers, but does that work reliably with flash in the variou= s=20 browsers? </FONT></SPAN></DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff si= ze=3D2><SPAN=20 class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff size=3D2>If s= o then it=20 seems like you are right that that this might be the best way to=20 go.</FONT></SPAN> </FONT></SPAN><SPAN class=3D437172516-07042004><FONT= =20 face=3DArial color=3D#0000ff size=3D2> </FONT></SPAN><SPAN=20 class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff size=3D2><SPA= N=20 class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff size=3D2>I ha= d been=20 thinking that a socket server would be the way to go for these ki= nds=20 of things. Does anybody have insight into the pros and cons of using the ht= tp=20 stream vs socket methods? </FONT></SPAN></DIV> <DIV> <DIV><SPAN class=3D437172516-07042004></SPAN> </DIV> <DIV><SPAN class=3D437172516-07042004>One pro that I can think of with the = http=20 streaming over socket connections or remote shared objects is the issue of= =20 properly closing connections. For example, I'm not really sure that when a= =20 browser is closed, that flash always gets notified and is given a chance to= =20 close the connection properly, possibly resulting in a browser crash with t= he=20 binary methods. In the http streaming method it seems like a poorly closed= =20 connection wouldn't be nearly as likely to crash the browser, if ever.=20 </SPAN><SPAN class=3D437172516-07042004><SPAN class=3D437172516-07042004><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>(In a rare case that'= s probably=20 still worth mentioning, someone's modem will sometimes trigger th= e=20 connection timeout rather than the browser, client or server = ;and=20 I'm not sure if the browsers even get notified then)</FONT></SPAN></DIV></S= PAN> <DIV><SPAN class=3D437172516-07042004></SPAN></FONT></SPAN> </DIV></DI= V> <DIV><SPAN class=3D437172516-07042004></SPAN><SPAN class=3D437172516-070420= 04><FONT=20 face=3DArial color=3D#0000ff size=3D2>I haven't responded to this discussio= n before as=20 it seems to me that remote shared objects, as awesome as they are for flash= =20 developers, seem more of a convienience method for flash developers th= an=20 something that enterprise developers would be interested in. After all isn'= t the=20 whole point of most of the J2EE architecture to provide enterprise level=20 persistence across servers? I think that remote shared objects would need m= ore=20 work to relate properly to these other mechanisms. Certainly ther= e are=20 about a billion java-based persistence mechanisms now. I could see shared=20 objects as a convienient caching mechanism though.</FONT></SPAN></DIV> <DIV><SPAN class=3D437172516-07042004></SPAN><SPAN=20 class=3D437172516-07042004></SPAN><SPAN class=3D437172516-07042004></SPAN><= SPAN=20 class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff si= ze=3D2>Just=20 my thoughts.</FONT></SPAN></DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D437172516-07042004><FONT face=3DArial color=3D#0000ff=20 size=3D2>-Cort</FONT></SPAN></DIV> <DIV><SPAN class=3D437172516-07042004></SPAN><SPAN class=3D437172516-070420= 04><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT face=3DTahom= a=20 size=3D2>-----Original Message-----<BR><B>From:</B> aglosband=20 [mailto:[EMAIL PROTECTED]<BR><B>Sent:</B> Wednesday, April 07, 2004= =20 10:33 AM<BR><B>To:</B> [email protected]<BR><B>Subject:</B>=20 [flexcoders] Re: Flex Needs Remote Shared Objects!<BR><BR></FONT></DIV><TT>= I=20 think this would be pretty easy to implement using HTTP Streaming.=20 <BR>Basically, the client makes an HTTP request to the server and the <BR>s= erver=20 holds the connection open until there is data to push down to <BR>the clien= t. I=20 believe this is the way some instant messaging <BR>applications work and so= lves=20 the problem of having to deal with <BR>firewall issues. Here's a javaworld= =20 article that shows how to do this <BR>with DHTML and servlets: <A=20 href=3D"http://www.javaworld.com/javaworld/jw-03-";>http://www.javaworld.com= /javaworld/jw-03-</A><BR>2000/jw-03-pushlet_p.html<BR><BR>-Alex=20 <BR><BR>--- In [email protected], "Stacy Young"=20 <[EMAIL PROTECTED]> <BR>wrote:<BR>> Maybe flex can generic "messagi= ng"=20 API via web service or something.<BR>> That way implementations would be= same=20 across Java/CF/.NET<BR>> <BR>> <BR>> <BR>> -S<BR>>=20 <BR>> <BR>> <BR>> _____ <BR>> <BR>> = From:=20 Dimitrios Gianninas <BR>> Sent: Monday, April 05, 2004 5:17 PM<BR>> T= o:=20 [email protected]<BR>> Subject: RE: [flexcoders] Flex Needs Rem= ote=20 Shared Objects!<BR>> <BR>> <BR>> <BR>> And of course this= will=20 have to be tied to the middleware somehow,<BR>> especially for point 3 o= f=20 Stacy's email. So it would have to be a <BR>Java<BR>> push? hmm.. don't= =20 know.<BR>> <BR>> <BR>> <BR>> Maybe Flex handles doing the= =20 push, but gets data from some service <BR>and<BR>> then sends it to all = the=20 client UIs.<BR>> <BR>> <BR>> <BR>> Jimmy Gianninas - Soft= ware=20 Developer<BR>> <BR>> Terra Payments Inc.<BR>> <BR>> (514) 380 -= 2700=20 extension 3249<BR>> <BR>> <BR>> <BR>> <BR>> <BR>>=20 <table width=3D800 cellpadding=3D4 cellspacing=3D10 border=3D0><tr= =20 <BR>bgcolor=3DBDBDBD><td valign=3Dtop width=3D400><font face=3D= verdana=20 size=3D2 <BR>color=3DFFFFFF><b>AVIS=20 IMPORTANT</b></font></td><td valign=3Dtop=20 <BR>width=3D400><font face=3Dverdana size=3D2=20 <BR>color=3DFFFFFF><b>WARNING</b></font></td><= ;/tr><tr><td=20 valign=3Dtop <BR>width=3D400><p align=3Djustify><font face=3Dve= rdana size=3D1=20 color=3D808080> <BR>Les informations contenues dans le present document = et ses=20 pieces <BR>jointes sont strictement confidentielles et reservees a l'usage = de la=20 <BR>(des) personne(s) a qui il est adresse. Si vous n'etes pas le=20 <BR>destinataire, soyez avise que toute divulgation, distribution, copie, <= BR>ou=20 autre utilisation de ces informations est strictement prohibee. Si <BR>vous= avez=20 recu ce document par erreur, veuillez s'il vous plait <BR>communiquer=20 immediatement avec l'expediteur et detruire ce document <BR>sans en faire d= e=20 copie sous quelque forme.</td><td valign=3Dtop <BR>width=3D400>= <p=20 align=3Djustify><font face=3Dverdana size=3D1 color=3D808080> <BR>= The=20 information contained in this document and attachments is <BR>confidential = and=20 intended only for the person(s) named above. If you <BR>are not the intende= d=20 recipient you are hereby notified that any <BR>disclosure, copying,=20 distribution, or any other use of the <BR>information is strictly prohibite= d. If=20 you have received this <BR>document by mistake, please notify the sender=20 immediately and destroy <BR>this document and attachments without making an= y=20 copy of any <BR>kind.</td></tr></table><BR><BR></TT></BOD= Y></HTML> ------=_NextPart_000_0002_01C41CA1.F33CB190--
