[webkit-dev] Pepper and NaCl supporting (prototype)

2013-07-01 Thread halton huo
Dear WebKit developers and users,

I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2]
support for WebKit2. The home page is located at
https://github.com/nacl-webkit/native_client/wiki.
The initial code include supporting of:
* Partial pepper api supporting includes: 2d, scripting, url_loader, file
chooser, audio, mouse and keyboard events, websockets.
* Basic NaCl support with post message api (HelloWorld from nacl_sdk)

There are some sceenshots on
https://github.com/nacl-webkit/native_client/wiki/Screenshots

QA
===
Q: Why this project?
A: We enjoy working with the WebKit projects. We also enjoy technologies
like NaCl, and wanted to lower the barrier to letting people integrate NaCl
into their WebKit2 based projects. We prototyped this work and now want to
make it available for others to use if they want.

Q: Can I modify and re-use the project?
A: Yes. The code is inherited from the Chromium, WebKit2 and native_client
projects. As such, this project follows the same licenses.

Q: Why not upstream?
A: There are two main reasons. First, the current code is only a prototype
to support NaCl in the Linux EFL port of WebKit2. There still remains work
to be done before the patches would be appropriate to try and take
upstream. Second, the WebKit community has stated in the past that they did
not want NaCl upstream.

Q: How to contribute?
A: Fork the repo on github and submit the pull request, committers will
review the patches. For the time being, the initial contributors are
committers, we're welcome to anyone who can show his ability to be as
committer. Follow the
https://github.com/nacl-webkit/native_client/wiki/Codeto get code and
build.

Q: Any next plan?
A: We don't have any formal plans for the project moving forward; it is
being developed as a part-time effort by a few engineers. As such, there is
no guarantee for future work. Again, anyone is welcome to contribute! Or
fork the project and run with it.

[1] http://code.google.com/p/ppapi/
[2] http://code.google.com/p/nativeclient/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Pepper and NaCl supporting (prototype)

2013-07-01 Thread Adam Barth
Very impressive.

If (like me) you're curious about what changes to WebKit are required
to make this work, I found the diff at the following URL:

https://github.com/nacl-webkit/webkit/compare/upstream_base...master

Adam


On Sun, Jun 30, 2013 at 11:41 PM, halton huo halton@gmail.com wrote:
 Dear WebKit developers and users,

 I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2]
 support for WebKit2. The home page is located at
 https://github.com/nacl-webkit/native_client/wiki.
 The initial code include supporting of:
 * Partial pepper api supporting includes: 2d, scripting, url_loader, file
 chooser, audio, mouse and keyboard events, websockets.
 * Basic NaCl support with post message api (HelloWorld from nacl_sdk)

 There are some sceenshots on
 https://github.com/nacl-webkit/native_client/wiki/Screenshots

 QA
 ===
 Q: Why this project?
 A: We enjoy working with the WebKit projects. We also enjoy technologies
 like NaCl, and wanted to lower the barrier to letting people integrate NaCl
 into their WebKit2 based projects. We prototyped this work and now want to
 make it available for others to use if they want.

 Q: Can I modify and re-use the project?
 A: Yes. The code is inherited from the Chromium, WebKit2 and native_client
 projects. As such, this project follows the same licenses.

 Q: Why not upstream?
 A: There are two main reasons. First, the current code is only a prototype
 to support NaCl in the Linux EFL port of WebKit2. There still remains work
 to be done before the patches would be appropriate to try and take upstream.
 Second, the WebKit community has stated in the past that they did not want
 NaCl upstream.

 Q: How to contribute?
 A: Fork the repo on github and submit the pull request, committers will
 review the patches. For the time being, the initial contributors are
 committers, we're welcome to anyone who can show his ability to be as
 committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code
 to get code and build.

 Q: Any next plan?
 A: We don't have any formal plans for the project moving forward; it is
 being developed as a part-time effort by a few engineers. As such, there is
 no guarantee for future work. Again, anyone is welcome to contribute! Or
 fork the project and run with it.

 [1] http://code.google.com/p/ppapi/
 [2] http://code.google.com/p/nativeclient/

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

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


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-07-01 Thread Ryosuke Niwa
On Sun, Jun 30, 2013 at 9:39 PM, Filip Pizlo fpi...@apple.com wrote:

 On Jun 19, 2013, at 9:41 AM, Dan Bernstein m...@apple.com wrote:

 
 
  On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:
 
  What about?
 
  StyleResolver* existingStyleResolver()
  StyleResolver styleResolver()
 
  I like it.
 
 
  — Timothy Hatcher
 
 
  On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org
 wrote:
 
  For me optional seems very misleading and generally different prefixes
 suggests that those objects are not the same.
  Maybe IfExists does not sound nicely but at least it's clear. I would
 choose to have a pointer version with IfExists and a reference version
 which is a noun, like:
 
  StyleResolver* styleResolverIfExists()

 I like this more. I like that the use of 'if' in the name alerts me to the
 fact that the function will return something conditionally.

 By contrast, existingFoo only makes sense to me if I'm already aware of
 the idiom. And although I probably will *become* aware of the idiom it will
 still nonetheless be one of many idioms that I have to be aware of, so I
 fear that I'll forget why Foo is qualified with existing. That's why I
 like fooIfExists - its super explicit about what is going on.


I concur.  Maybe
StyleResolver* styleResolverIfExists()
StyleResolver styleResolver()
?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-07-01 Thread Brady Eidson

On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Sun, Jun 30, 2013 at 9:39 PM, Filip Pizlo fpi...@apple.com wrote:
 On Jun 19, 2013, at 9:41 AM, Dan Bernstein m...@apple.com wrote:
 
 
 
  On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:
 
  What about?
 
  StyleResolver* existingStyleResolver()
  StyleResolver styleResolver()
 
  I like it.
 
 
  — Timothy Hatcher
 
 
  On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:
 
  For me optional seems very misleading and generally different prefixes 
  suggests that those objects are not the same.
  Maybe IfExists does not sound nicely but at least it's clear. I would 
  choose to have a pointer version with IfExists and a reference version 
  which is a noun, like:
 
  StyleResolver* styleResolverIfExists()
 
 I like this more. I like that the use of 'if' in the name alerts me to the 
 fact that the function will return something conditionally.
 
 By contrast, existingFoo only makes sense to me if I'm already aware of the 
 idiom. And although I probably will *become* aware of the idiom it will still 
 nonetheless be one of many idioms that I have to be aware of, so I fear that 
 I'll forget why Foo is qualified with existing. That's why I like 
 fooIfExists - its super explicit about what is going on.
 
 I concur.  Maybe
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 ?

I concur with this.

For this entire discussion, this is where I was hoping it was headed.

Thanks,
~Brady

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


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-07-01 Thread Dan Bernstein

On Jul 1, 2013, at 7:31 PM, Brady Eidson beid...@apple.com wrote:

 
 On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Sun, Jun 30, 2013 at 9:39 PM, Filip Pizlo fpi...@apple.com wrote:
 On Jun 19, 2013, at 9:41 AM, Dan Bernstein m...@apple.com wrote:
 
 
 
  On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:
 
  What about?
 
  StyleResolver* existingStyleResolver()
  StyleResolver styleResolver()
 
  I like it.
 
 
  — Timothy Hatcher
 
 
  On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:
 
  For me optional seems very misleading and generally different prefixes 
  suggests that those objects are not the same.
  Maybe IfExists does not sound nicely but at least it's clear. I would 
  choose to have a pointer version with IfExists and a reference version 
  which is a noun, like:
 
  StyleResolver* styleResolverIfExists()
 
 I like this more. I like that the use of 'if' in the name alerts me to the 
 fact that the function will return something conditionally.
 
 By contrast, existingFoo only makes sense to me if I'm already aware of 
 the idiom. And although I probably will *become* aware of the idiom it will 
 still nonetheless be one of many idioms that I have to be aware of, so I 
 fear that I'll forget why Foo is qualified with existing. That's why I 
 like fooIfExists - its super explicit about what is going on.
 
 I concur.  Maybe
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 ?
 
 I concur with this.
 
 For this entire discussion, this is where I was hoping it was headed.

On second and third thought, I do think these are better.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Pepper and NaCl supporting (prototype)

2013-07-01 Thread halton huo
Hi Adam,

Yes, you're correct.

Besides webkit patches, chromium and native_client patches are:
https://github.com/nacl-webkit/chrome_deps/compare/upstream_base...master
https://github.com/nacl-webkit/native_client/compare/upstream_base...master

Thanks,
Halton.


On Mon, Jul 1, 2013 at 4:11 PM, Adam Barth aba...@webkit.org wrote:

 Very impressive.

 If (like me) you're curious about what changes to WebKit are required
 to make this work, I found the diff at the following URL:

 https://github.com/nacl-webkit/webkit/compare/upstream_base...master

 Adam


 On Sun, Jun 30, 2013 at 11:41 PM, halton huo halton@gmail.com wrote:
  Dear WebKit developers and users,
 
  I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2]
  support for WebKit2. The home page is located at
  https://github.com/nacl-webkit/native_client/wiki.
  The initial code include supporting of:
  * Partial pepper api supporting includes: 2d, scripting, url_loader, file
  chooser, audio, mouse and keyboard events, websockets.
  * Basic NaCl support with post message api (HelloWorld from nacl_sdk)
 
  There are some sceenshots on
  https://github.com/nacl-webkit/native_client/wiki/Screenshots
 
  QA
  ===
  Q: Why this project?
  A: We enjoy working with the WebKit projects. We also enjoy technologies
  like NaCl, and wanted to lower the barrier to letting people integrate
 NaCl
  into their WebKit2 based projects. We prototyped this work and now want
 to
  make it available for others to use if they want.
 
  Q: Can I modify and re-use the project?
  A: Yes. The code is inherited from the Chromium, WebKit2 and
 native_client
  projects. As such, this project follows the same licenses.
 
  Q: Why not upstream?
  A: There are two main reasons. First, the current code is only a
 prototype
  to support NaCl in the Linux EFL port of WebKit2. There still remains
 work
  to be done before the patches would be appropriate to try and take
 upstream.
  Second, the WebKit community has stated in the past that they did not
 want
  NaCl upstream.
 
  Q: How to contribute?
  A: Fork the repo on github and submit the pull request, committers will
  review the patches. For the time being, the initial contributors are
  committers, we're welcome to anyone who can show his ability to be as
  committer. Follow the
 https://github.com/nacl-webkit/native_client/wiki/Code
  to get code and build.
 
  Q: Any next plan?
  A: We don't have any formal plans for the project moving forward; it is
  being developed as a part-time effort by a few engineers. As such, there
 is
  no guarantee for future work. Again, anyone is welcome to contribute! Or
  fork the project and run with it.
 
  [1] http://code.google.com/p/ppapi/
  [2] http://code.google.com/p/nativeclient/
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 

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