[Laszlo-dev] serverless operation

Thu Dec 30 14:25:09 PST 2004

Hi Adam,

I'm not sure I have anything constructive to say on the security question,
but I am quite interested in the serverless development question and thought
to share with you my thoughts.

I would suggest something like an additional parameter("host"?) that could
be set to something like "static" or "dynamic" and to keep the cache type
independent of the original downloading mechanism.

The reason I say this is that the strength of serverless deployment is that
it allows the use of inexpensive shared web servers as the host for the
lion's share of an applications bandwidth use. Nevertheless I think that
there will usually still be some sort of server communcation and in some
cases it will still be with LPS. There will definitely be some variation.

For an example, I imagine having two hosts, one a vanilla shared html server
(like dreamhost) with a lot of throughput allowed each month at a cost of
very few ducats, but where you can't set up tomcat. All images, sound media
and animation and even the original swf would be downloaded from there.

A seperate host, one which allows tomcat but which doesn't allow a lot of
bandwidth use would be used for LPS. It would just take care of the control
information, sending messages between clients and managing state.

It may seem silly to split things up that way, but that's the hand we're
dealt. There are plenty of static html oriented hosts that give you lot's of
bandwidth and some dynamic hosts that allow you a lot of configuration
control, but few (if any) which do both inexpensivly. I can't think of any
problems with it technically and in terms of hosting dollars it would be
significant.

Glad to hear things are coming along so well,

-Cort

> -----Original Message-----
> From: laszlo-dev-bounces at openlaszlo.org
> [mailto:laszlo-dev-bounces at openlaszlo.org]On Behalf Of Adam Wolff
> Sent: Thursday, December 30, 2004 12:53 PM
> To: OpenLaszlo platform development and bug reporting
> Subject: [Laszlo-dev] serverless operation
>
>
> Hi. I've been working on some of the serverless APIs in the 3.0
> branch, and I have some questions about API and an implementation
> note. The general topic here is the set of APIs that allow a Laszlo
> app to bypass the running LPS and load XML data and swf, jpeg, mp3
> or swideo media directly from the web.
>
> Most of the work to make datasets able to load XML directly has been
> done (by someone else.) This is can currently be enabled in a Laszlo
> program by writing
>      <dataset transport="direct"
>
> I have done the work to make a Laszlo program able to load media
> directly. This was surprisingly easy. The entry point I chose was
> the setSource method in .../lfc/transformers/LzMakeLoad.as
>
> It has this signature:
>      LzMakeLoad.setSource = function ( newSrc , cache , headers ){
>
> My proposal is to change the argument called "cache" to some other
> word, and allow a 5th token (in addition to "none" , "clientonly" ,
> "serveronly" , and "both") which would be "serverless", since these
> dispositions are mutually exclusive. Does anyone have a better name
> for this argument than "cache"? NB that we could use "direct"
> instead of "serverless", but I like the latter better. Either way,
> this token should match the one used for dataset transport.
>
> It also seems to me that in most cases, a Laszlo program which wants
> to bypass the LPS, wants to do so in all cases. I propose that we
> add an attribute to the canvas called "serverless". If true, this
> means that by default, all datasets and runtime resources are loaded
> directly, rather than by proxy through the LPS. This default can be
> over-ridden (either way) by setting the transport attribute of a
> dataset, or by calling setSource witch a different [cache] argument.
>
> Finally, there's a bit of an implementation gotcha that I wanted to
> surface. The security policy in the Flash player is notoriously
> baroque, and I don't want to go into detail on the various
> combinations of swf format, player version number, and scripting
> possiblities that lead to different behaviors. Also, in my
> experience (and the experience of others here) the behavior
> documented by Macromedia doesn't match the actual behavior. Anyway,
> here's a tech note if you want to get into all that:
>
> http://www.macromedia.com/devnet/mx/flash/articles/fplayer_securit
> y_04.html
>
> The reason I bring this up is that the security policy makes it so
> that a container flash movie loaded from one domain cannot call
> *any* methods on a flash move loaded from a different domain. Sadly,
> this includes getBytesLoaded() and getBytesTotal(), which is the way
> the LFC tracks load progress (and as far as I know, the *only* way.)
> This is important, because the LFC has its own notion of open
> connections and load callbacks and such.
>
> As I see it, there are three general ways to handle this:
>
> 1) Handle this by exposing/handling Flash security
> This would mean identifying all the various player + movie format
> possibilities (flash player 7 loads swf 6 which loads swf 5 asset --
> etc,) testing them to verify that the documented behavior
> matches the specified behavior, and then implementing a set of APIs
> that account for the combinations as simply as possible.
> This strikes me as a non-starter. It would pollute our APIs with a
> lot of Flash specific garbage, and it would make for some pretty
> complicated tests that would have to be run in a number of different
> flash players.
> The advantage here is that we might be able to normalize this stuff
> in Flash, and it would be nice to able to do the right thing so that
> you can load media from anywhere on the web and get full load
> information on it.
>
> 2) Allow this, but don't handle it well
> When a movie bumps into this security issue, the LFC can tell
> because the function getBytesLoaded becomes undefined for that movie
> clip. We could make it so that the LFC treats a movie like this as
> if it had loaded. We could also create flag, or a special value for
> loadperc (that's the LFC attribute for load percentage) that tells a
> Laszlo program that it has hit this limitation.
>
> Note that this is a fairly serious deficiency. An app like Soundblox
> (http://soundblox.blogspot.com/) would not be able to show any load
> information. The app would only know that the load has started. In
> most media players that we've done here at Laszlo, we have some
> fairly extensive code that tries to determine the rate at which
> media is loading so that we have some sense of when the buffer is
> big enough to start playing. Not only would this strategy remove the
> load information, the app would never even know if the load was
> done.  This would also create problems for the LFC's LzLoadQueue
> service, which relies on knowing when a load has completed to know
> how many connections it has open.
>
> 3) Don't handle this at all
> If you do this, the app never gets notified that a load has started.
> The LFC never changes its internal state to account for the fact
> that the connection may have closed. Do this twice, and your app
> won't load any more media.
>
> This is arguably the cleanest solution but it's probably confusing
> for developers (especially since app behavior will vary widely in
> different players) until they search the docs pretty carefully. It
> also prevents the Soundblox usecase entirely.
>
>
> I'm obviously in favor of number 2, but I'd be willing to hear
> arguments in favor of number 1.  It seems to me that the common case
> won't bump into this at all, but there really is a class of apps
> that will be affected by this.
>
> Adam
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev