It doesn't have to be the same server. XMLSocket and XML are subject
to the same crossdomain.xml policy security model.

-bob

On 2/19/07, Theo <[EMAIL PROTECTED]> wrote:
>
> Absolutely, go with Flash, Ajax doesn't add anything useful in this
> case. Flash is capable of doing everything you want, and involvning
> one more environment in this is asking for trouble.
>
> In Flash you have two options on how to load the data, either you do a
> HTTP call, like in Ajax (look at XML.load in the Flash documentation)
> or you can open a socket connection directly to your backend (look at
> XMLSocket in the Flash documentation). The latter would probably give
> you the best realtime experience, since you don't have the overhead of
> HTTP and you can push data from the backend. However, to use sockets
> there are additional security constraints, for example you need to be
> able to run your backend on a port number greater than 1023 on the
> same server that the swf-file is retrieved from.
>
> T#
>
> On Feb 18, 1:14 am, "Bob Ippolito" <[EMAIL PROTECTED]> wrote:
> > On 2/17/07, iain duncan <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> > > > > Unless you do something very complex or weird there isn't going to be
> > > > > any latency to speak of. The ExternalInterface is quite quick, I doubt
> > > > > you will have any problems there.
> >
> > > > > I have no idea of what you mean when you say "control elements in the
> > > > > flash clip via ajaxy calls to a server". It seems rather backwards to
> > > > > involve server calls in the controlling part. I can understand if you
> > > > > want to load data to display but don't involve it in the
> > > > > controlling...
> >
> > > Ok, thanks again. What I mean is that there will be shapes in a flash
> > > clips, already made via either actionscript or aflax, but their
> > > positions will change in real time based on coordinates coming from an
> > > external real time process. The idea is actually to be able to use flash
> > > animations synced up to real time events coming from a C++ or python app
> > > that embeds the csound audio engine, running on the same local machine
> > > as the flash process. The purpose is to try to allow one to use flash
> > > for visuals instead of openGL as I know a lot of flash animators who
> > > don't know openGL.
> >
> > > I imagined maybe what could happen is that a browser shows a flash clip,
> > > the flash clip somehow makes asynchronous requests to find the current
> > > position for the shapes, and the requests will in prototype go to a
> > > light weight server that makes a socket connection to my C++ app ( that
> > > in turn embeds csound and traps into the csound engine for the real time
> > > data ). Eventually I would like to cut out the server and figure out the
> > > fastest way to get data from the C++ app to flash, but in the meantime,
> > > short ajax requests that are only asking for x,y coordinates seem like
> > > they would be pretty quick.
> >
> > You don't need JavaScript for that. I did something *very* similar
> > about 6 years ago by embedding the Flash ActiveX control in a C++ app
> > (and polling variables that C++ would set). I've also done it with
> > just XMLSocket and no C++ container.
> >
> > Getting JavaScript involved would be a big mistake. Stick with ActionScript.
> >
> > -bob
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to