Geoffrey Garen wrote:
The most recent effort from our side is to provide WebRTC support.
Great. Features, like performance improvements and bug fixes, are a
great way to contribute to WebKit.
As it was pointed in the first email of this thread and by Hugo's
email, Nix "targets whoever wants to have a hardware accelerated
WebKit2 port on UNIX-based devices, with a minimum effort”.
Yes. I read that email. Then I asked who “whoever” was, and the answer
was “nobody”.
My position is simply this: Every port has a cost, so every port needs
at least a prima facia explanation of its corresponding benefit.
If the NIX port is what gets you guys excited about WebKit, and the
end result is a great implementation of WebRTC, that’s great.
But, six months from now, if the NIX port still has no adopters, and
the only activity it brings to WebKit is the occasional rude email
from Ossy, that’s not so great.
TDLR: Crank Software Supports a NIX port
I would like to throw my support behind incorporating the Nix port into
the tree. Our company, Crank Software
(www.cranksoftware.com) focuses on embedded user interfaces and graphics
and as a part of that we have
provided a number of customers with WebKit support and offer our own
WebKit based browser product that
integrates with Storyboard Suite (www.cranksoftware.com/storyboard).
You don't hear about these ports because they are typically embedded
within other products where the goal of
the 'browser' is not to be a general purpose browser, but provide more
of a product specific role in presenting
a user interface in a potentially non-network connected system.
These ports never get upstreamed to WebKit.org because they aren't of
broad general interest, frequently rely on
proprietary toolchains or hardware technology (CPU, graphics) that are
not generally accessible and frequently
have significant feature removals or disablements to meet the
constraints of embedded systems and custom
product environments. This of course makes it hard for the WebKit
community to 'see' our activities, but we are
active and present non-the-less.
Our builds are uniformly cmake based (because we can get cmake to fit
with any toolchain and platform we encounter)
and frequently use a POSIX based API for platforms as the system
interaction abstraction layer. This helps
enormously as we can develop a shim posix library on platforms where
required which is much easier than trying
to interpret the frequently undocumented and changing behaviour of
WebKit raw operations.
To us there would be enormous value in upstreaming a generic Nix based
port because it would represent
something that we could track and also participate in its growth
development and general improvement as
we support other systems "behind the scenes".
Thanks,
Thomas
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
