[Vortex] [ANN] Vortex Library 1.0.17 'Lost keys' release is ready!

[Francis Brosnan Blazquez]

Hi Robert,

> Is this available to play around with it? 

Sure. First download current svn status from jsVortex:

https://dolphin.aspl.es/svn/publico/af-arch/trunk/jsVortex/

Then follow these instructions:

http://www.aspl.es/jsVortex/docs

...inside section "How to configure a local jsVortex regression test". 

You can skip (step 4) all stuff that is associated to Firefox since the
reg test is now by default running java socket connector.

> Is the Java route a better one  
> than using Flash, which supports sockets as well?

I think it is better because:

1) The java applet provides real sockets API while Flash socket contents
has problem with \0 (or something similar). I saw this somewhere but I'm
able to find now the particular problem.

2) Flash security model is not well defined being changed across
versions. It tends to be defined in a way that the user is not asked
causing lot of problems. For example, you can run sockets without any
restriction or you may require a policy server running at port 843, on
the server where the flash was downloaded (or similar), to allow sockets
and again depending on your flash version. This is not the case of java
applet since it is signed and the user accept or not the applet.

3) Due to Java, we have a really large/complete socket API, including
TLS extensions. I'm not sure it we have something similar with flash (we
didn't find it). 

4) Integration with JavaScript is well defined with Java. This is not
the case for Flash (just see ExternalInterface API).

In general I found that people that was using flash as bridge are having
lot of problems starting with Flash 9.

In the order hand the advantage of Flash is that it is more available
than Java applet...but I find this not too much problematic specially on
comercial environments...

> > The unofficial plan (;-) is to fully integrate WebSocket protocol into
> > Vortex, Turbulence, jsVortex, PyVortex...providing support to write and
> > expose BEEP services on top of WebSocket API which is an appealing idea.
> 
> Good. Looking forward how things evolve. And I keep wondering why people  
> mess around with low level protocol design if there is BEEP...

Me too...I think it is a matter of proposing alternatives, especially
for the server side. Cheers!

-- 
Francis Brosnan Blazquez <francis at aspl.es>
ASPL