[Laszlo-dev] Fwd: some tantalizing comments aboutloadingassetsfrom external swfs

David Temkin temkin at laszlosystems.com
Tue Jan 11 10:38:40 PST 2005


One problem with the runtime fetch for all resources within dynamic
libraries ("plan B") is exactly the if-modified-since processing. If you're
running with LPS, you'll get if-modified-since requests going all the way to
the original file for each resource you load, every time you load the app.
This is going to be a major performance issue... so it pushes the "how do
you do expires headers with LPS" issue -- again.

- D. 


> From: Eric Bloch <bloch at laszlosystems.com>
> Reply-To: OpenLaszlo platform development and bug reporting
> <laszlo-dev at openlaszlo.org>
> Date: Tue, 11 Jan 2005 10:13:04 -0800
> To: <hqm at alum.mit.edu>, OpenLaszlo platform development and bug reporting
> <laszlo-dev at openlaszlo.org>
> Subject: Re: [Laszlo-dev] Fwd: some tantalizing comments
> aboutloadingassetsfrom external swfs
> 
> BW Optimization for "plan B"
> 
> You'd probably want the server to do If-Mod-Since/Last-Mod caching on
> these assets (and even possible Expires/Cache-Control: Age, too).
> 
> You'll get If-Mod-Since/Last-Mod for free with LZServlet but you'll be
> responsible for making this work yourself in the "servlet-less" mode.  I
> believe you can config Apache or most other decent web servers for this
> automatically.  Servlet-containers won't do this automatically, though.
> 
> -Eric
> 
> 
> Henry Minsky wrote:
> 
>> Thanks for looking at this!
>> 
>> It looks like we are going to have to go with "plan B" for loading
>> assets from libraries at runtime, which Oliver suggested, which is to
>> have some scheme where the compiler converts any static resource
>> declarations into individual HTTP requests and load each resource
>> separately on demand. Since most HTTP servers support keeping the
>> connection open, I don't think it will be too bad in terms of
>> performance.
>> 
>> 
>> On Tue, 11 Jan 2005 08:48:18 -0800 (PST), rpiwork at notebookmargins.com
>> <rpiwork at notebookmargins.com> wrote:
>> 
>>> Hi Henry,
>>> 
>>> I'm afraid the fellow either misunderstood what was happening or
>>> miscommunicated what he was trying to do. I checked about a half a dozen
>>> variations on what he posted this morning and the only thing that works is
>>> the basic case that I described yesterday and which one would expect to
>>> work.
>>> 
>>> Here are the details of what I tested, you can download the files if you'd
>>> like to tweak them some more.
>>> http://www.notebookmargins.com/link_from_public/lzattach/
>>> 
>>> Sorry the style and structure are so goofy, I was just throwing the tests
>>> together quickly.
>>> http://www.notebookmargins.com/link_from_public/lzattach/test_attach_interfa
>>> ce.html
>>> 
>>> There are 2 swfs, test_attach_interface.swf loads initially
>>> // test_attach_interface.swf
>>> // has 3 buttons
>>> // no library symbols (other than the button and the "target" symbol)
>>> // and a movieclip on it's stage named "target_mc"
>>> 
>>> // The first button loads testattach.swf into target_mc
>>> on(press){
>>>        this.target_mc.loadMovie("testattach.swf"); // works fine
>>> }
>>> 
>>> // Now testattach.swf
>>> // has a button
>>> // a bunch of colored lib symbols named "s1", "s2", "s3","s4" with the
>>> same linkage references as their names
>>> // and a movieclip on it's stage named "Dummy_mc"
>>> // It's button has this code which obviously works and loads a tan square
>>> (s1)
>>> on(press){
>>>        this.Dummy_mc.attachMovie("s1","s1_mc",this.getNextHighestDepth());
>>> }
>>> // Dummy_mc also has this code on it's timeline to be tested later from
>>> the main interface
>>> attachItem = function(target, name){
>>>        trace("called");
>>>        trace(target);
>>>        trace(name);
>>>   var mc:MovieClip = target.attachMovie("s4", name,
>>> target.getNextHighestDepth());
>>>        trace(mc);
>>>   return mc;
>>> }
>>> 
>>> // The second button in test_attach_interface.swf tells the newly loaded
>>> clip to attach
>>> // a different (blue) symbol to it's local scope
>>> on(press){
>>>        this.target_mc.Dummy_mc.attachMovie("s2","s2_mc",2); // works fine
>>> }
>>> 
>>> // The third button in test_attach_interface.swf has a bunch of tests that
>>> don't work
>>> // and one that does, but which is essentially the same as the code in the
>>> second button
>>> // and is what I think the livedocs poster was doing.
>>> on(press){
>>>        // obviously won't work
>>>        // this.attachMovie("s3","s3_mc",2);
>>> 
>>>        // Less obviously, like that which was what was described in the
>>> post,
>>> but still doesn't work
>>>        // var new_mc:MovieClip = this.target_mc.Dummy_mc.attachItem(this,
>>> "newName");
>>>        // trace(new_mc);                               // undefined
>>>        // trace(new_mc._name);    // undefined
>>> 
>>>        // another variation of the same thing, dynamically attaches the
>>> function
>>> to dummy_mc
>>>        // this one is as described by the poster, the fn gets called, but
>>> the
>>> attach still doesnt' work
>>>        // this.target_mc.Dummy_mc.attachItem2 = function(target_mc, name){
>>>        //        trace("called2");
>>>        //   var mc:MovieClip = target_mc.attachMovie("s4", "s4_mc",
>>> target_mc.getNextHighestDepth());
>>>        //   trace(mc); // undefined
>>>        //   return mc;
>>>        //}
>>>        // var new_mc:MovieClip = this.target_mc.Dummy_mc.attachItem2(this,
>>> "newName");
>>>        // trace(new_mc);                               // undefined
>>>        // trace(new_mc._name);    // undefined
>>> 
>>>        // What does work, but which is essentially the same as button 2
>>>        // notice that when we move the parent's x position to 200 the whole
>>> target_mc group is moved
>>>        var new_mc:MovieClip =
>>> this.target_mc.Dummy_mc.attachItem(this.target_mc,
>>> "newName_mc");
>>>        trace(new_mc);
>>>        new_mc._parent._x = 200;
>>> }
>>> 
>>> // Now I also tried a number of other minor variations just to be certain
>>> // (like trying target_mc instead of target_mc.Dummy_mc to be identical to
>>> the poster's description).
>>> // but if this were going to work it would have worked in the third
>>> version of that third button.
>>> // I'm certain that even if there were something like this that were to
>>> work it would be unsupported
>>> // and unreliable as well.
>>> 
>>> 
>>>> Thanks very much! Let us know what you find out.
>>>> 
>>>> Henry
>>>> 
>>>> 
>>>> 
>>>> On Mon, 10 Jan 2005 09:43:01 -0500, Cortlandt Winters
>>>> <cort at notebookmargins.com> wrote:
>>>> 
>>>>> I'll try what he say's he did as well, but I don't believe that it will
>>>>> work.
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: laszlo-dev-bounces at openlaszlo.org
>>>>>> [mailto:laszlo-dev-bounces at openlaszlo.org]On Behalf Of Cortlandt
>>>>> 
>>>>> Winters
>>>>> 
>>>>>> Sent: Monday, January 10, 2005 9:16 AM
>>>>>> To: hqm at alum.mit.edu; OpenLaszlo platform development and bug
>>>>> 
>>>>> reporting
>>>>> 
>>>>>> Subject: RE: [Laszlo-dev] Fwd: some tantalizing comments about
>>>>>> loadingassetsfrom external swfs
>>>>>> 
>>>>>> 
>>>>>> Hi Henry,
>>>>>> 
>>>>>> I think that, as you suspect, the post is a little misleading
>>>>>> here for your
>>>>>> purposes. He's not attaching the dynamically loaded library symbol to
>>>>> 
>>>>> the
>>>>> 
>>>>>> scope of the original loading timeline. He's just calling a
>>>>>> function on the
>>>>>> scope of the loaded movieclip which can attach it's own library
>>>>>> symbols and
>>>>>> be displayed as a result. This will work though.
>>>>>> 
>>>>>> So if you have Main.swf loading Assets1.swf Main can attach it's
>>>>> 
>>>>> symbol's
>>>>> 
>>>>>> dynamically and Assets1 can attach it's symbols dynamically, but
>>>>>> Main can't
>>>>>> attach Assest1's symbols to it's scope, the best it can do is call a
>>>>>> function in Assets, have it attach a symbol to it's local scope and
>>>>> 
>>>>> then
>>>>> 
>>>>>> manipulate the Assets1.swf.
>>>>>> 
>>>>>> This obviously could create problems if you have 2 symbols from the
>>>>>> Assets1.swf that you are trying to manipulate simultaneously and
>>>>>> independently. You could duplicate the library swf, but that would be
>>>>> 
>>>>> a
>>>>> 
>>>>>> waste of memory for anything large, so I'm afraid lz would
>>>>>> probably want to
>>>>>> load them each as independent swfs unless the assets are really small.
>>>>>> 
>>>>>> If you would like a simple example to look at I can create one either
>>>>> 
>>>>> at
>>>>> 
>>>>>> lunch or this evening if nobody does so before then.
>>>>>> 
>>>>>> -Cort
>>>> 
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> Laszlo-dev at openlaszlo.org
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>> 
>>> 
>>> 
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev




More information about the Laszlo-dev mailing list