Re: [webkit-dev] deleteOwnedPtr(T* ptr)
Umm... shouldn't this behavior be commented so that people are not left
wondering why it fails and trying to fix it?
On Wed, Nov 10, 2010 at 16:04, Darin Adler da...@apple.com wrote:
On Nov 10, 2010, at 2:33 PM, Daebarkee Jung wrote:
I found that the following lines made errors:
// OwnPtrCommon.h
template typename T inline void deleteOwnedPtr(T* ptr)
{
typedef char known[sizeof(T) ? 1 : -1];
if (sizeof(known))
delete ptr;
}
I am very curious about why the author wrote like the above.
What could be the author's intention?
The code is to prevent issues like the ones described on these websites:
http://stackoverflow.com/questions/1767679/incomplete-type-memory-leaks
http://bytes.com/topic/c/answers/611877-gcc-class-forward-declarations-destructor-calls
http://connect.microsoft.com/VisualStudio/feedback/details/231177/delete-of-pointer-to-incomplete-class
If we delete a pointer and the object has incomplete type, we get undefined
behavior. Instead this code causes compilation to fail if the object has
incomplete type. The use of a negative number for the size of an array is a
way to guarantee we get a compilation error.
Your alternate version might also work; I’m not sure.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HTML5 Web Links (RFC 5988)
Gavin wrote in https://lists.webkit.org/pipermail/webkit-dev/2010-November/015026.html: Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin That sounds great. Two thoughts: - please do not forget to take the anchor parameter into account -- either drop the header when it's present, or use it to determine the context of the link (see http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.2) - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
Hi Alexey, thank you for sharing your thought. I agree that using platform APIs for testing is better than using mocks. On the other hand, I believe the automated testing is our invaluable assert. And some real API is hard to automate. Here is a conflict. I think we need both. Currently WebKit has3 mocks under platform/mock - DeviceOrientationClientMock - GeolocationServiceMock - SpeechInputClientMock It looks that these features are hard to automate without mocks. Another advantage of mocked test is that it is easier to have high code coverage than others, due to the ease to control which mocks provide. So having these mocks somewhere out of WebCore looks a reasonable compromise if we have some manual test counterparts for mocked automated tests. But I'd like to hear the implementors voice, as Alexey hoped so. -- morrita On Thu, Nov 11, 2010 at 2:53 AM, Alexey Proskuryakov a...@webkit.org wrote: Sorry for a delayed response - I hoped for someone else to weigh in. This approach is certainly better than having code in shipping WebCore. But I still think that testing via platform APIs is much more desirable than implementing and maintaining a separate pseudo-API for mocks. This can't be too bad for productivity either - the social contract seems to be that you implement DumpRenderTree for one or two platforms at most, and file bugs for others. - WBR, Alexey Proskuryakov 27.10.2010, в 22:08, Hajime Morita написал(а): Hi Alexey, thank you for revising this topic! I understand your concern about having a testing infrastructure inside the production code. On the other hand, having separate but similar mocks for each port hurts our productivity. And we cannot automate testing without mocks anyway. So how about to have separate WebCoreTesting library/framework? The WebCoreTesting will: - access WebCore types directly, as WebKit library does - have mock implementations of WebCore-provided interfaces (abstract classes) and - WebCore will provide abstract classes and injection points for their intenaces, but not provide class implementations - WebKit will provide a priviate method to enable the mocks, which uses WebKitTesting. WebKitTesting library will be linked lazily (using weak symbol mechanism for Mac, or dlopen() family for other ports.) In this approach, we - can split the testing infrastructure out from the production code, just by removing WebCoreTesting library. - can share mock implementations between ports. Even with this approach, some redundancy remains in WebCore, like abstract class for mocks. But actual code, which is a possible cause of vulnerability, can be removed from the production. I once prototyped that approach for introducing WebCore::LayoutTestController. So the patch might help to see what I meant to say: https://bug-42612-attachments.webkit.org/attachment.cgi?id=63403 (Note this patch has rough edges and need to polish anyway.) Believing what I proposed above is a reasonable tradeoff between security/efficiency and productivity, I wonder there might be other possibilities to explore. So I'd love to hear from you and any folks who have interest. Regards. -- morrita On Thu, Oct 28, 2010 at 4:07 AM, Alexey Proskuryakov a...@webkit.org wrote: 02.08.2010, в 4:38, Alexey Proskuryakov написал(а): 29.07.2010, в 8:16, Adam Barth написал(а): Plumbing this mock API all the way through WebKit for each port seems like a waste. One benefit of this is that it makes us test the API layer. Another one is that it gives WebKit developers better familiarity with APIs - that's not as minor as it sounds, as some of us (including myself) have limited knowledge of WebKit APIs, even for their favorite platform. It certainly seems like a waste when private methods are added just for DumpRenderTree support. But maybe it has prompted an API introduction a few times before, I just don't know. This is all getting much better with WebKit2's cross-platform API, although of course we'll need to support current APIs for a long time. This thread died, but I still don't feel good about mock objects in WebCore. Having test infrastructure in WebCore means shipping unused code in the framework, and as mentioned before, we lack testing of the API layer. We're now getting more mock objects in the tree, such as one for speech synthesis testing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] deleteOwnedPtr(T* ptr)
Thanks, all of you.
Now, everything is clear.
Daebark
On Thu, Nov 11, 2010 at 2:24 AM, Finnur Thorarinsson fin...@chromium.orgwrote:
Umm... shouldn't this behavior be commented so that people are not left
wondering why it fails and trying to fix it?
On Wed, Nov 10, 2010 at 16:04, Darin Adler da...@apple.com wrote:
On Nov 10, 2010, at 2:33 PM, Daebarkee Jung wrote:
I found that the following lines made errors:
// OwnPtrCommon.h
template typename T inline void deleteOwnedPtr(T* ptr)
{
typedef char known[sizeof(T) ? 1 : -1];
if (sizeof(known))
delete ptr;
}
I am very curious about why the author wrote like the above.
What could be the author's intention?
The code is to prevent issues like the ones described on these websites:
http://stackoverflow.com/questions/1767679/incomplete-type-memory-leaks
http://bytes.com/topic/c/answers/611877-gcc-class-forward-declarations-destructor-calls
http://connect.microsoft.com/VisualStudio/feedback/details/231177/delete-of-pointer-to-incomplete-class
If we delete a pointer and the object has incomplete type, we get
undefined behavior. Instead this code causes compilation to fail if the
object has incomplete type. The use of a negative number for the size of an
array is a way to guarantee we get a compilation error.
Your alternate version might also work; I’m not sure.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11 November 2010 03:59, Julian Reschke julian.resc...@gmx.de wrote: Gavin wrote in https://lists.webkit.org/pipermail/webkit-dev/2010-November/015026.html: Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin That sounds great. Two thoughts: - please do not forget to take the anchor parameter into account -- either drop the header when it's present, or use it to determine the context of the link (see http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.2) - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). Thanks Julian! I'll consider these points carefully. - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] deleteOwnedPtr(T* ptr)
On Nov 11, 2010, at 12:24 AM, Finnur Thorarinsson wrote: Umm... shouldn't this behavior be commented so that people are not left wondering why it fails and trying to fix it? Sure, sounds good. Instructions for submitting patches to add things like those comments are at http://webkit.org/coding/contributing.html. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] deleteOwnedPtr(T* ptr)
Do or do not. Then, there is no question. :)
btw, in another code base, you may familiar with, the comment is the
variable name:
http://www.google.com/codesearch?q=type_must_be_completeexact_package=chromium
On Thu, Nov 11, 2010 at 12:24 AM, Finnur Thorarinsson
fin...@chromium.orgwrote:
Umm... shouldn't this behavior be commented so that people are not left
wondering why it fails and trying to fix it?
On Wed, Nov 10, 2010 at 16:04, Darin Adler da...@apple.com wrote:
On Nov 10, 2010, at 2:33 PM, Daebarkee Jung wrote:
I found that the following lines made errors:
// OwnPtrCommon.h
template typename T inline void deleteOwnedPtr(T* ptr)
{
typedef char known[sizeof(T) ? 1 : -1];
if (sizeof(known))
delete ptr;
}
I am very curious about why the author wrote like the above.
What could be the author's intention?
The code is to prevent issues like the ones described on these websites:
http://stackoverflow.com/questions/1767679/incomplete-type-memory-leaks
http://bytes.com/topic/c/answers/611877-gcc-class-forward-declarations-destructor-calls
http://connect.microsoft.com/VisualStudio/feedback/details/231177/delete-of-pointer-to-incomplete-class
If we delete a pointer and the object has incomplete type, we get
undefined behavior. Instead this code causes compilation to fail if the
object has incomplete type. The use of a negative number for the size of an
array is a way to guarantee we get a compilation error.
Your alternate version might also work; I’m not sure.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] deleteOwnedPtr(T* ptr)
On Nov 11, 2010, at 7:20 AM, Darin Adler wrote: On Nov 11, 2010, at 12:24 AM, Finnur Thorarinsson wrote: Umm... shouldn't this behavior be commented so that people are not left wondering why it fails and trying to fix it? Sure, sounds good. Instructions for submitting patches to add things like those comments are at http://webkit.org/coding/contributing.html. Even better than a comment would be to use the COMPILE_ASSERT macro. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 00:59, Julian Reschke написал(а): - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. [*] the approach is to support raw non-ASCII bytes in Content-Disposition file name, decoded as UTF-8 - and if that fails, as referring document's encoding, and if that fails, as browser default encoding. See http://trac.webkit.org/browser/trunk/WebCore/loader/FrameLoader.cpp?rev=71625#L2689. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11.11.2010 18:06, Alexey Proskuryakov wrote: 11.11.2010, в 00:59, Julian Reschke написал(а): - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list athttps://code.google.com/p/chromium/issues/detail?id=57830). As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 9:19, Julian Reschke написал(а): As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Raw bytes seem to be the most common representation for non-ASCII file names on the Web. Implementing that fixed all bug reports I had about Web compatibility in that respect (except for GMail, of course), and didn't cause new ones. Some examples were Yahoo! Mail, several file sharing services, and several Korean forums. This is not surprising, as that's the only way to make a download link that works in both IE and Firefox (at least for target audiences, see below). Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). The Encoding Sniffing column looks somewhat misleading to me, because browsers interpret raw bytes differently. I don't know if any browser sniffs encoding in the common sense of the word. But both IE and Firefox support raw bytes in Content-Disposition, although in different ways. IE: Uses Language for non-Unicode programs setting. So with the system language set to Russian, Content-Disposition is interpreted as windows-1251 (Cyrillic). I'm not sure what it does if decoding fails. Firefox: Tries UTF-8, then referring document's encoding, then Latin-1. Safari: Tries UTF-8, then referring document's encoding, then browser default encoding, and then Latin-1, which can never fail. The IE's mechanism is obviously the weakest - it only works if the file name encoding happens to match local user default. But that's almost always the case for end users. Anyway, if a certain Content-Disposition with raw bytes works in IE _or_ Firefox, it's almost certain to work in Safari, too. If the link works in both, it's pretty certain to work in Safari. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Perhaps I misunderstood your comment or was unclear myself - I don't have a strong opinion about RFC2231-style encoding. It seems cleaner than raw bytes, but with de facto standard being raw bytes, it also seems superfluous. I would welcome it if the standard described what to do with raw bytes, because that's the practical case both browser and server developers need to work with. Obviously, I think that Safari solution is best for browsers (with possible addition of RFC2231/5988 support). It would seem very weird and unfortunate to me if file names were looked up in both Content-Disposition and Link header fields. This is what I referred to as two sources. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 11.11.2010 20:10, Alexey Proskuryakov wrote: 11.11.2010, в 9:19, Julian Reschke написал(а): As far as the Chromium request goes, please consider feature parity with Safari. We've supported non-ASCII file names in Content-Disposition for a while now, and judging by the lack of bug reports, our approach[*] is sufficient for Web compatibility. The only issue I know is with GMail, which blocks Safari server-side, replacing non-ASCII characters with question marks. Do you have information on how frequently it's used? Raw bytes seem to be the most common representation for non-ASCII file names on the Web. Implementing that fixed all bug reports I had about Web compatibility in that respect (except for GMail, of course), and didn't cause new ones. Some examples were Yahoo! Mail, several file sharing services, and several Korean forums. This is not surprising, as that's the only way to make a download link that works in both IE and Firefox (at least for target audiences, see below). Judging from http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-03.html#rfc.section.C.4 it's not supported in IE, Opera, and Konqueror, so it's definitively not interoperable today (besides, it conflicts with the existing definitions for the header). The Encoding Sniffing column looks somewhat misleading to me, because browsers interpret raw bytes differently. I don't know if any browser sniffs encoding in the common sense of the word. But both IE and Firefox support raw bytes in Content-Disposition, although in different ways. Oh, I called it sniffing because according to HTTP/1.1 it's ISO-8859-1, and some browsers sniff for different encodings. IE: Uses Language for non-Unicode programs setting. So with the system language set to Russian, Content-Disposition is interpreted as windows-1251 (Cyrillic). I'm not sure what it does if decoding fails. Firefox: Tries UTF-8, then referring document's encoding, then Latin-1. Safari: Tries UTF-8, then referring document's encoding, then browser default encoding, and then Latin-1, which can never fail. Thanks for the details, my data in http://greenbytes.de/tech/tc2231/#attwithisofnplain and http://greenbytes.de/tech/tc2231/#attwithutf8fnplain was based on blackbox testing. The observable effect, from testing in a Western European locale, is that the UAs do not interoperate; some stick to 8859-1 (Konq, Opera, IE), some sniff (Safari, Chrome, FF). The IE's mechanism is obviously the weakest - it only works if the file name encoding happens to match local user default. But that's almost always the case for end users. Anyway, if a certain Content-Disposition with raw bytes works in IE _or_ Firefox, it's almost certain to work in Safari, too. If the link works in both, it's pretty certain to work in Safari. Indeed; and I wasn't even aware of that because I'm testing with the local I'm in. I don't think the IETF will ever approve a standard where the encoding depends on the recipient's locale, with no reliable way to find out upfront what that locale is. Having two sources of file name information in HTTP headers sounds like a very weird idea to me. ... It's the format that has been an IETF standard for a VERY long time. If you have concerns with this format then you *really* should raise them in the IETF HTTPbis WG, which is revising the spec for Content-Disposition, and plans to submit it for publication soon (it's already past IETF Working Group Last Call). Perhaps I misunderstood your comment or was unclear myself - I don't have a strong opinion about RFC2231-style encoding. It seems cleaner than raw bytes, but with de facto standard being raw bytes, it also seems superfluous. I disagree that raw bytes are a de facto standard; they do not interoperate across UAs (see above)... I would welcome it if the standard described what to do with raw bytes, because that's the practical case both browser and server developers need to work with. Obviously, I think that Safari solution is best for browsers (with possible addition of RFC2231/5988 support). The spec (RFC 2616) already says that raw bytes are ISO-8859-1, so UAs overriding this are in violation of the spec (IMHO). Introducing a separate parameter (filename*) that doesn't carry the legacy problems is in my opinion the best way to move forward. It would seem very weird and unfortunate to me if file names were looked up in both Content-Disposition and Link header fields. This is what I referred to as two sources. Ah, so that was a misunderstanding. I was referring to the fact that Link: uses the same *encoding* (RFC 5987) for the title parameter (not filename). So if a UA was to process Link headers for, for instance, chapter titles, it could parse title* to discover I18Nized chapter titles. So no overlap with C-D, except that maybe the library for decoding RFC5987-encoded parameters could be re-used. Best regards, Julian
[webkit-dev] Webkit GTK Animation -- blocks main loop and after Animation timer expiry it loads the rest of the Page.
Hi All, I Built GtkLauncer. Whenever i tried to load Page which is having animation , GTK Webkit browser Blocks main loop and displays animation after animation timer expiry it again starts loading Page. Any one as any issues with pages having animation. Any help on how to make animation not to block main event loop is appreciated. Thanks, Varma ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
11.11.2010, в 11:38, Julian Reschke написал(а): I don't think the IETF will ever approve a standard where the encoding depends on the recipient's locale, with no reliable way to find out upfront what that locale is. Yes, that makes good sense to me. Note that Safari's doesn't rely on OS locale (other than for picking its original default browser encoding, which can then be changed by the user). Surely, some people are allergic to the idea of default browser encoding too, but it's unavoidable in practice - we can't interpret untagged content as Latin-1. I disagree that raw bytes are a de facto standard; they do not interoperate across UAs (see above)... I think that we agree about technical details and empirical data now, but describe them differently. Surely, there is no way (that I'm aware of) to guarantee correct downloaded file name in all browsers for all users. A lot of server operators only care about users in their country, and can reasonably (i.e. with negligible cost to business) rely on Windows locale being set. They can just send raw bytes in language default encoding in Content-Disposition, and that works for them and their clients. For all I know, that's what almost everyone does, and it's interoperable for them. Global operators like Google or Yahoo obviously want to cover many languages at once, and they just send different HTTP headers to different browsers. That's not great, but that's unavoidable unless IE changes - whether changing interpretation of raw bytes or implementing RFC5987, IE would have to change. The spec (RFC 2616) already says that raw bytes are ISO-8859-1, so UAs overriding this are in violation of the spec (IMHO). Yes, that's why I'd really welcome a spec that's closer to reality in this regard. No browser whose vendor cares about markets not covered by Latin-1 can actually treat raw bytes in Content-Disposition as ISO-8859-1. No server operator who wants to serve downloadable content in those markets can stick to ISO-8859-1. Introducing a separate parameter (filename*) that doesn't carry the legacy problems is in my opinion the best way to move forward. As a browser implementor, I don't have a strong opinion about filename*. The actual content I see on the Web uses raw bytes in Content-Disposition, so I mostly care about that being adequately specified, so that at least non-IE browsers could all work the same. Firefox and Safari are already pretty close. It's unfortunate if Chrome does not implement this fallback scheme. Generally speaking, having no custom encoding is better than having an opaque custom encoding. In my opinion, the ideal situation would be for servers to send raw UTF-8, and for clients to do what Safari and Firefox do (try UTF-8, then fall back to other encodings). This may be unachievable in practice, in which case interoperability via opaque RFC2231-style encoding is a lesser evil. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] support for media streaming
Hello, I am totally new to this browser plugin stuff. I would like to know if there is a support for media streaming such as mp3 audio video in webkit my intension is to make use of some thirdparty NPAPI plugin which can handle audio/video stream integrate the plugin with the webkit to achieve streaming. Could you please give me some pointers on this. your inputs are highly appreciated. Thanks Satish -- View this message in context: http://old.nabble.com/support-for-media-streaming-tp30170240p30170240.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
