Re: [Crosswalk-dev] Intent to Implement: WebAudio API for audio clock synchronization

2016-03-08 Thread Alexis Menard 
Hi,

> -Original Message-
> From: Crosswalk-dev [mailto:crosswalk-dev-bounces@lists.crosswalk-
> project.org] On Behalf Of Raphael Kubo da Costa
> Sent: Tuesday, 8 March, 2016 10:11
> To: crosswalk-dev@lists.crosswalk-project.org
> Subject: Re: [Crosswalk-dev] Intent to Implement: WebAudio API for audio
> clock synchronization
> 
> "Pozdnyakov, Mikhail"  writes:
> 
> > Description:
> > Implementation of the WebAudio API[1] extension that allows web
> > developers to synchronize audio stream playing with other events in
> > DOM. Pls. see [2] for the proposed API description and [3] for
> > motivation and WG discussions around this topic.
> >
> > Platform: Windows
> >
> > [1] https://www.w3.org/TR/webaudio/
> > [2] https://github.com/WebAudio/web-audio-api/pull/754
> > [3] https://github.com/WebAudio/web-audio-api/issues/12
> 
> Things which are not clear to me after reading this message:
> - This looks more like something to be implemented in Chromium than in
>   Crosswalk. What's the situation in Chromium regarding this feature?

We want to experiment with the API, shipping a working prototype for the W3C
member to play with. It was decided that it's too early for us to go to
Chromium route. Compare it to the presentation API. 

> - Why do we need this in Crosswalk for Windows? And why is this not
>   needed for other platforms?

It requires hardware and support in the OS, Android and Linux are out of
scope for lack of support.

> - Can you describe in a few lines what kind of work will be done in
>   Crosswalk (e.g. what needs to be plugged into what)?
> ___
> Crosswalk-dev mailing list
> Crosswalk-dev@lists.crosswalk-project.org
> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Implement: WebAudio API for audio clock synchronization

2016-03-08 Thread Raphael Kubo da Costa 
"Pozdnyakov, Mikhail"  writes:

> Description:
> Implementation of the WebAudio API[1] extension that allows web
> developers to synchronize audio stream playing with other events in
> DOM. Pls. see [2] for the proposed API description and [3] for
> motivation and WG discussions around this topic.
>
> Platform: Windows
>
> [1] https://www.w3.org/TR/webaudio/
> [2] https://github.com/WebAudio/web-audio-api/pull/754
> [3] https://github.com/WebAudio/web-audio-api/issues/12

Things which are not clear to me after reading this message:
- This looks more like something to be implemented in Chromium than in
  Crosswalk. What's the situation in Chromium regarding this feature?
- Why do we need this in Crosswalk for Windows? And why is this not
  needed for other platforms?
- Can you describe in a few lines what kind of work will be done in
  Crosswalk (e.g. what needs to be plugged into what)?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Intent to Implement: WebAudio API for audio clock synchronization

2016-03-08 Thread Pozdnyakov, Mikhail 
Description:
Implementation of the WebAudio API[1] extension that allows web developers to 
synchronize audio stream playing with other events in DOM. Pls. see [2] for the 
proposed API description and [3] for motivation and WG discussions around this 
topic.

Platform: Windows

[1] https://www.w3.org/TR/webaudio/
[2] https://github.com/WebAudio/web-audio-api/pull/754
[3] https://github.com/WebAudio/web-audio-api/issues/12

BR,
Mikhail
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Open Discussion about Cordova Plugin Crosswalk WebView for iOS

2016-03-08 Thread Ahmed Hassan 
Hi everyone,

its interesting to see this discussing and i would like to bring in my opinion 
as a developer working with a hybrid stack for mobile app development a while 
now.
To answer the first question: Do we really need iOS support for the crosswalk 
WebView?

From my point of view the only possible answer can be the question behind what 
value would it really add for any hybrid developer out there?
As far as i can see it there was a time, not long ago, where two different 
WebViews for iOS existed. The old UiWebView and the new WkWebView. During this 
time people where urged to use the new web view because of significant 
preformance improvements but it was not working correctly on all versions of 
iOS and people started to write fallbacks and stuff. This is now obsolete as 
the Adoption for iOS 9 is one of the best i have seen out there. So using the 
new Version of Cordova with the WkWebview as a default should be an easy 
decision when targeting iOS with Cordova.

Crosswalk solves a problem that exists and will still exist in the future. The 
fragmentation of the Android Devices and the underlying OS. Adoption rates for 
the current android version are horribly bad, but luckily we can wrap our apps 
with a non native web view. For iOS apple dos not allow any other web views for 
their platform. So where is the value for me as a developer, when i am sure 
that the underlying web view will be WkWebView. Unifying APIs? I think this is 
done by the Web Standards, and adoption is a decision Apple will have to make. 
I can’t see a proper way to start polyfilling browser features for iOS that are 
not already implemented. There is no urgent need for the majority of the 
community to do that. WkWebView is doing a quite good job. If there is one 
specific thing you are missing for your project it would be straight forward to 
add a cordova plugin that allows you to do use this feature, for example 
getUserMedia. And it would be really confusing to know crosswalk as unifying 
the web view by using chromium, but for iOS its simply not doing that.

I think focusing on one problem and having the best solution, is what we really 
need and expect from crosswalk. And the problem is with Android.
And i think there is also more to add there, as we are a bit behind the release 
track and the new versions of chromium add a lot of improvements and new 
features, to the web view.
If its possible to use a different underlying browser on iOS, its time to move 
forward and add iOS to crosswalk. But maybe this will never happen.

Hope that helps and to hear your thoughts.

All the best
Ahmed



> Am 08.03.2016 um 03:55 schrieb Dong, Jonathan :
> 
> Hi Crosswalk folks,
>  
> Recently we’ve come across an issue in Cordova Plugin Crosswalk WebView for 
> iOS support, and I think it could be worthy to discuss here. Recently I’m 
> working on enabling iOS support incordova-plugin-crosswalk-webview 
>  
> project (which only supports Android platform for now) by integrating a 
> prebuilt library of crosswalk-ios 
> , as Crosswalk for iOS is 
> implemented based on the WKWebView introduced by iOS 8, it requires the 
> minimum Cordova version to be 6.0.0 above and Cordova-iOS version to be 4.0.0 
> above. Because Cordova plugin mechanism does not provide the plugin users to 
> choose which platform to adopt among its supported platforms, it means the 
> existing cordova-plugin-crosswalk-webivew users whose application also 
> support iOS platform will face the upgrade pain (from UIWebView to WKWebView 
> based Crosswalk XWalkView, and upgrade Cordova & Cordova-iOS as well) once 
> the Crosswalk-19 is get released. There’s already a discussion based this PR: 
> https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/pull/81 
> 
>  
> So the questions could be: 
> 1.   Do we really need to enable iOS support within 
> cordova-plugin-crosswalk-webview?
> 2.   If the answer to question 1 is yes, how do we minimize the upgrade 
> pain to the existing plugin user whose application also support iOS?
>  
> My thoughts about question 1 is this could be a good chance to prompt the 
> adoption of Crosswalk project for iOS, but the risk we have to take is the 
> upgrade pain for the plugin users as described above, which would result of 
> complaint or even user lost. And we could create a standalone Cordova plugin 
> project which contains only Crosswalk XWalkView for iOS, this solution won’t 
> break the current usage of the cordova-plugin-crosswalk-webview project, but 
> it will break the common design idiom of Cordova Plugin (support as more 
> platform as it could within on plugin, by my understanding), and we will lose 
> the chance to prompt Crosswalk project for iOS.
>  
> For question