[webkit-dev] Announcing new port: Nix

[Thomas Fletcher]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130912/ee87eddb/attachment.html>