yep thats fine. But thining about it I may have actually saved it on the i drive in:
i drive. > bms > public > tommy But if its not there give me a call on Thursday at some point - I'll be around till about 2 Tommy ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, August 28, 2007 1:27 PM Subject: Red5 Digest, Vol 24, Issue 132 > Send Red5 mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://osflash.org/mailman/listinfo/red5_osflash.org > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Red5 digest..." > > > Today's Topics: > > 1. Re: Shared Object vs. invoke (Storm) > 2. Re: Shared Object vs. invoke (Naicu Octavian) > 3. problems when sending ByteArray to RED (Stanis?aw Fiedor) > 4. Re: Shared Object vs. invoke (Mike) > 5. Re: Shared Object vs. invoke (Naicu Octavian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Aug 2007 08:32:58 +0200 > From: Storm <[EMAIL PROTECTED]> > Subject: Re: [Red5] Shared Object vs. invoke > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > I agree with everything said here, but i must add something to defend poor > nc.call's :) > > SOs may have a bad behaviour in some extreme cases such as updating right > before disconnecting and such. I've had to change some functionality from > SOs to nc.calls due to this, those "few bytes" of the callbacks are pretty > useful to ensure that the update has been really recieved. Therefor > everything has its place, even in a one-to-all update scenario. > > Cheers > > On 8/28/07, Joachim Bauch <[EMAIL PROTECTED]> wrote: > > > > Dominick Accattato schrieb: > > [...] > > > Now, if you were talking about using the SharedObject.send method, you > > > may not need to bubble up to your application code, but your still being > > > sent to all the clients. That being said, you should just use the > > > sharedObjects sync functionality anyway. > > > > using so.send or SO syncs even saves you a few bytes bandwidth as for > > nc.call, the client sends back the result of the method call to the > > server (or the server back to the client) which isn't done for SO events. > > Well, just a few bytes ;) but if you have lots of calls... > > > > Joachim > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > -- > ------------------------------------------------------------------- > If a man speaks in a forest and his wife is not there, is he still wrong? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/9567b85d/ attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 28 Aug 2007 11:23:45 +0300 > From: "Naicu Octavian" <[EMAIL PROTECTED]> > Subject: Re: [Red5] Shared Object vs. invoke > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > >I agree with everything said here, but i must add something to defend poor > nc.call's :) > > Another thing is that with nc.call calls for the server to the clients you > can target specific clients. A ns.send sends the info to all clients > subscribed to that SO. This is a more general issue but good to have in mind > when one is developing a private messages feature for example! :) > > -- > Naicu Octavian, > Project Manager for AVChat > http://www.avchat.net > > On 28/08/07, Storm <[EMAIL PROTECTED]> wrote: > > > > I agree with everything said here, but i must add something to defend poor > > nc.call's :) > > > > SOs may have a bad behaviour in some extreme cases such as updating right > > before disconnecting and such. I've had to change some functionality from > > SOs to nc.calls due to this, those "few bytes" of the callbacks are pretty > > useful to ensure that the update has been really recieved. Therefor > > everything has its place, even in a one-to-all update scenario. > > > > Cheers > > > > On 8/28/07, Joachim Bauch <[EMAIL PROTECTED]> wrote: > > > > > > Dominick Accattato schrieb: > > > [...] > > > > Now, if you were talking about using the SharedObject.send method, you > > > > may not need to bubble up to your application code, but your still > > > being > > > > sent to all the clients. That being said, you should just use the > > > > sharedObjects sync functionality anyway. > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth as for > > > nc.call, the client sends back the result of the method call to the > > > server (or the server back to the client) which isn't done for SO > > > events. > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > Joachim > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > -- > > ------------------------------------------------------------------- > > If a man speaks in a forest and his wife is not there, is he still wrong? > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/a56d9e84/ attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Tue, 28 Aug 2007 12:21:18 +0200 > From: Stanis?aw Fiedor <[EMAIL PROTECTED]> > Subject: [Red5] problems when sending ByteArray to RED > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > Hi, > I'm passing a function in flex to call it on the RED5 server with a parametr which is of the ByteArray type. (nc.call("myFunc",null,aByteArray);) > Unfortunately I'm getting an error: > > INFO] 2007-08-28 12:09:40,859 SocketAcceptorIoProcessor-0.1:( org.red5.io.amf3.Input.readDataType ) Unknown datatype: 12 > [ERROR] 2007-08-28 12:09:40,859 SocketAcceptorIoProcessor-0.1:( org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer ) Error decoding buffer > org.red5.server.net.protocol.ProtocolException: Error during decoding > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode(RTMPProtocolDecode r.java:201) > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer(RTMPProtocol Decoder.java:121) > at org.red5.server.net.rtmp.codec.RTMPMinaProtocolDecoder.decode(RTMPMinaProtoc olDecoder.java:60) > at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod ecFilter.java:156) > at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299) > at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoF ilterChain.java:53) > at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece ived(AbstractIoFilterChain.java:648) > at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageRecei ved(AbstractIoFilterChain.java:499) > at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299) > at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(Abs tractIoFilterChain.java:293) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcesso r.java:211) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProce ssor.java:181) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoPr ocessor.java:44) > at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoPr ocessor.java:448) > at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java: 39) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.IllegalArgumentException > at java.nio.Buffer.limit(Unknown Source) > at org.red5.io.amf.Input.readString(Input.java:227) > at org.red5.io.object.Deserializer.deserialize(Deserializer.java:68) > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeFlexMessage(RTMPPro tocolDecoder.java:870) > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeMessage(RTMPProtoco lDecoder.java:542) > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodePacket(RTMPProtocol Decoder.java:405) > at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode(RTMPProtocolDecode r.java:187) > ... 17 more > Well... does RED5 actually support bytearrays? - Cause amfphp does... so I guess that red should also... has anybody a clue? > > BR > > stf > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/68c26270/ attachment-0001.html > > ------------------------------ > > Message: 4 > Date: Tue, 28 Aug 2007 08:11:59 -0400 > From: Mike <[EMAIL PROTECTED]> > Subject: Re: [Red5] Shared Object vs. invoke > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Good point, Octavian. > Suppose I only want to send position data to players that are within a > certain range. > > For example, anyone within 100 "meters". > > SharedObjects don't really give me that luxury, do they? > I may be forced to use nc.call? > Or, is there another method? > > Is there a version of nc.call that does NOT require a return message? > > Naicu Octavian wrote: > > >I agree with everything said here, but i must add something to defend > > poor nc.call's :) > > > > Another thing is that with nc.call calls for the server to the clients > > you can target specific clients. A ns.send sends the info to all > > clients subscribed to that SO. This is a more general issue but good > > to have in mind when one is developing a private messages feature for > > example! :) > > > > -- > > Naicu Octavian, > > Project Manager for AVChat > > http://www.avchat.net > > > > On 28/08/07, *Storm* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I agree with everything said here, but i must add something to > > defend poor nc.call's :) > > > > SOs may have a bad behaviour in some extreme cases such as > > updating right before disconnecting and such. I've had to change > > some functionality from SOs to nc.calls due to this, those "few > > bytes" of the callbacks are pretty useful to ensure that the > > update has been really recieved. Therefor everything has its > > place, even in a one-to-all update scenario. > > > > Cheers > > > > > > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Dominick Accattato schrieb: > > [...] > > > Now, if you were talking about using the SharedObject.send > > method, you > > > may not need to bubble up to your application code, but your > > still being > > > sent to all the clients. That being said, you should just > > use the > > > sharedObjects sync functionality anyway. > > > > using so.send or SO syncs even saves you a few bytes bandwidth > > as for > > nc.call, the client sends back the result of the method call > > to the > > server (or the server back to the client) which isn't done for > > SO events. > > Well, just a few bytes ;) but if you have lots of calls... > > > > Joachim > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > -- > > ------------------------------------------------------------------- > > If a man speaks in a forest and his wife is not there, is he still > > wrong? > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Aug 2007 15:27:31 +0300 > From: "Naicu Octavian" <[EMAIL PROTECTED]> > Subject: Re: [Red5] Shared Object vs. invoke > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > >Suppose I only want to send position data to players that are within a > certain range. For example, anyone within 100 "meters". > > Your mileage will vary. If you have 1000 connected users and in each 100m > radius there are only 10 users then nc.call can be a good decision! but in > such a case you can also have a SO for each 100mx100m sqare radius,etc... > .Depends on what you are trying to do! > > On 28/08/07, Mike <[EMAIL PROTECTED]> wrote: > > > > Good point, Octavian. > > Suppose I only want to send position data to players that are within a > > certain range. > > > > For example, anyone within 100 "meters". > > > > SharedObjects don't really give me that luxury, do they? > > I may be forced to use nc.call? > > Or, is there another method? > > > > Is there a version of nc.call that does NOT require a return message? > > > > Naicu Octavian wrote: > > > >I agree with everything said here, but i must add something to defend > > > poor nc.call's :) > > > > > > Another thing is that with nc.call calls for the server to the clients > > > you can target specific clients. A ns.send sends the info to all > > > clients subscribed to that SO. This is a more general issue but good > > > to have in mind when one is developing a private messages feature for > > > example! :) > > > > > > -- > > > Naicu Octavian, > > > Project Manager for AVChat > > > http://www.avchat.net > > > > > > On 28/08/07, *Storm* <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > I agree with everything said here, but i must add something to > > > defend poor nc.call's :) > > > > > > SOs may have a bad behaviour in some extreme cases such as > > > updating right before disconnecting and such. I've had to change > > > some functionality from SOs to nc.calls due to this, those "few > > > bytes" of the callbacks are pretty useful to ensure that the > > > update has been really recieved. Therefor everything has its > > > place, even in a one-to-all update scenario. > > > > > > Cheers > > > > > > > > > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > Dominick Accattato schrieb: > > > [...] > > > > Now, if you were talking about using the SharedObject.send > > > method, you > > > > may not need to bubble up to your application code, but your > > > still being > > > > sent to all the clients. That being said, you should just > > > use the > > > > sharedObjects sync functionality anyway. > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth > > > as for > > > nc.call, the client sends back the result of the method call > > > to the > > > server (or the server back to the client) which isn't done for > > > SO events. > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > Joachim > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] <mailto:[email protected]> > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------- > > > If a man speaks in a forest and his wife is not there, is he still > > > wrong? > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] <mailto:[email protected]> > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/9e1ee68a/ attachment.html > > ------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > End of Red5 Digest, Vol 24, Issue 132 > ************************************* > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.10/976 - Release Date: 27/08/2007 18:20 > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
