Re: content-loading mechanism questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alan,

On Friday 05 March 2004 12:20 pm, alan hill wrote:
> >On the second point, we don't use an iframe for menu items since
> >iframes tend to be egregiously expensive in terms of memory
> >resources. If your app doesn't _really_ need an iframe, you might
> >look into the NW content loading mechanism.
>
> I always assumed netWindows used iframes for its content-loading. 

It does, but it only uses a single iframe over which it multiplexes 
requests. The contents of the returned documents are copied out of 
the document and into the specified target container. There's a 
client-side queue that is maintained to ensure that content loading 
is robust. All in all, it's a lot of work that NW does to avoid 
multiple iframes and make sure loading content is fairly dependable.

The point that NW tries to work around isn't that you shouldn't use 
iframes, it's that they get expensive VERY quickly. I've seen apps 
that brought systems to a grinding halt just by creating a lot of 
iframes. It's not pretty.

> May I ask what it does use?  Offhand, the alternative loading
> methods would be XMLHTTP (not supported by all target platforms),

But very close. Mozilla/Safari now include document.load, and Safari 
1.2 has XMLHTTP. Opera is the only hold-out in this regard.  There is 
a method in NW to use XMLHTTP when it is available to get the "raw" 
text of a document. NW_getFileText() from netWindows.js takes two 
arguments, the URL to be fetched and (optionally) a boolean 
indicating whether or not the result should be cached. Note that this 
is a _synchronous_ get and that NW_getFileTextAsync() (whose second 
argument is a callback function pointer instead of a boolean) is 
available for async needs. As you point out, this isn't an option 
everywhere, but for some things, it's a godsend.

As an aside, we use XMLHTTP for "regular" content loading on IE 5.0 
since it doesn't support what we do for iframe manipulation on 
standards-compliant browsers.

> dynamically appending script tags using the DOM, 

This doesn't work in Safari/Konq. As far as I can tell through 
lxr.kde.org, it's _still_ not working in HEAD. You can add an element 
alright, and you can even set it's src property, but the item won't 
be fetched and/or parsed.

> setting cookies
> (javascript calls for dummy image and sends a query string, server
> sets cookies) or by using a java applet.  

While there's no "hard" 4K limit for cookie sizes, the RFC states that 
user agents must accept _at least_ 4096 bytes of cookie data per 
domain, which some UA's correctly interpret as the point at which 
they can start ignoring more data. Can't blame 'em for that, but it 
does make this a somewhat painful transit mechanism.

> Have I missed something?

Nope! I think you got 'em all = )

> Still on the content-loader, are there any plans to "modularise" it
> as with the signals and slots?

I did this once upon a time, but it's so painful to extract it out of 
__env__ and re-name all of the methods from __util__ that the content 
loader requires. It's not a task I take on unless someone REALLY 
needs just the content loader queue. The sigslot library has been 
very careful to ensure that it doesn't use things from other core NW 
objects and avoids using browser features which it doesn't ensure are 
available. environ_core.js wasn't written this way and it hasn't been 
a big goal of mine. Sorry.

Regards

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFASPC0oV0dQ6uSmkYRArquAKCVMsaPAoalJFHHPnC0Ipxze8eX3wCcClOL
3levPp/UmupFZXmNDm3eNh8=
=cFZO
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org