Re: [webkit-dev] XMLHttpRequest and readyState==3

2007-06-26 Thread Maciej Stachowiak


On Jun 26, 2007, at 10:29 AM, Christopher Allen wrote:


Geoffrey Garen wrote:

From code inspection, I see that XMLHttpRequest updates responseText
every time it receives data.

Perhaps you're seeing the results of slightly different networking
implementations. For example, you might need to send data in larger
chunks in order to convince the networking layer to flush its data  
up to

the application level.


We've written up a simple example using perl cgi and js/xhr to
demonstrate this problem. In Firefox, the expected behavior appears.
Every second, a new line appears counting up from 1 to 10. In Safari,
there's a 10 second delay with nothing, and then 10 lines appear
counting up from 1 to 10 all at once, just as the readyState goes from
3 to 4. We never see readyState going from 3 to 3 as we do with
Firefox.

URL demonstrating this behavior: http://www.synchroedit.com/pt/

URL with source code for this test:
http://www.synchroedit.com/pt/perl-test.tar.gz

The perl cgi script has autoflushing enabled, which means the buffer
is flushed for every newline. In Firefox, the responseText is updated
whenever the perl side sends and flushes data, while Safari's
responseText stays empty until the perl cgi closes the connection and
the request enters readyState 4.

So to return back to our original question -- this capability is
needed for synchronous applications that keep an ongoing connection to
the server to avoid polling and other performance issues. Is this
capability supposed to be to in Safari, thus our test above
demonstrates a bug? Are we missing something? Is there an alternative
approach that would make this behavior work right in WebKit/Safari 3
as well?


This is a networking layer issue - it buffers the data up to some  
limit depending on what MIME type you send it with. Two workarounds  
that I think will work:


1) prime the connection with 256 bytes sent before any of the real  
data.
2) Use a MIME type that won't be subject to sniffing (I think  
application/xml as opposed to text/xml may fit the bill).


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Future of Webkit for Windows?

2007-06-26 Thread Arno


On Jun 26, 2007, at 11:09, Darin Adler wrote:


On Jun 26, 2007, at 11:00 AM, Double-Dee Zee wrote:
does the use of non-redistributable support libraries force Adobe  
to maintain their own WebKit branch?



No.

Adobe should bring their changes back into the webkit.org tree,  
using ifdefs as appropriate.


we, Adobe, plan to do the following:

a/ merge the latest WebKit top-of-tree with our changes (we're  
waiting for a certain Jesus-device to be released before doing so)


b/ publish our branch as we make available future public beta builds  
of Apollo


b/ submit our changes back to WebKit top-of-tree. This will happen as  
soon as we ship Apollo 1.0.


We have no intention of forking our branch.

Note that we are using Cairo to render on Windows, not Quartz. We are  
not using CoreFoundation either. The availability of both of those  
libraries when Safari shipped were interesting surprises, but we do  
not expect to change our plan at this point.


Cheers,
Arno.
Apollo/AIR Engineering Manager.
Adobe.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Re: Future of Webkit for Windows?

2007-06-26 Thread Alp Toker

Arno wrote:


On Jun 26, 2007, at 11:09, Darin Adler wrote:


On Jun 26, 2007, at 11:00 AM, Double-Dee Zee wrote:
does the use of non-redistributable support libraries force Adobe to 
maintain their own WebKit branch?



No.

Adobe should bring their changes back into the webkit.org tree, using 
ifdefs as appropriate.


we, Adobe, plan to do the following:

a/ merge the latest WebKit top-of-tree with our changes (we're waiting 
for a certain Jesus-device to be released before doing so)


b/ publish our branch as we make available future public beta builds of 
Apollo


b/ submit our changes back to WebKit top-of-tree. This will happen as 
soon as we ship Apollo 1.0.


We have no intention of forking our branch.

Note that we are using Cairo to render on Windows, not Quartz. We are 
not using CoreFoundation either. The availability of both of those 
libraries when Safari shipped were interesting surprises, but we do not 
expect to change our plan at this point.


Hi,

I've been working on the WebKit Cairo backend for the last couple of
months as part of the Gtk+ port (but the code is entirely cross-platform).

In that time we've fixed up the core GraphicsContextCairo, added initial
SVG support and are working on Canvas support. You can track our
progress in the SVN history and the bug tracker. Could you explain with
a little more detail how your contributions merge against the current
tip-of-tree so we can coordinate our efforts and avoid duplication?

If there are any specific areas you think need work, I'd be happy to
look into them personally or work together with your team.

Cheers,
Alp

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] How to make S60 webkit installed on a symbian 3rd cellphone such as n71

2007-06-26 Thread 黎明
I have complier s60 webkit using ARM RealView 2.2, also make a sis file.But
I can't make the sis file install on my N71. It looks like that the
self-sign sis can't get the capabilities S60 Webkit need such as
NetworkControl. I also found that most mmp project use CAP_CLIENT_DLL MACRO
to get ALL -TCB capabilities. It's a manufacturer approval level
capabilities. My question is: Is s60 webkit open source to independent
develop? In general , get a manufacturer approval capabilities is not
possible for an independent developer.

I found that xmlengine.dll and pagescaler.dll are not source code available.
The two dlls require capabilities can 't gain through self-sign.

Did anyone make s60 webkit actual run on a Symbian 3rd cellphone? 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev