One other random thought. It's admittedly ugly, but I think worth
bringing up just the same:
What effort would be involved in making the old Futon interface usable
in CouchDB 2, possibly even without exposing all the features? Would
that be less effort/faster than porting Fauxton? I know the interface is
old and clunky, and doesn't support all CDB 2.x features, but (assuming
no similar licensing restrictions), even an old (and possibly limited)
interface might be a better option for some, than the pain of installing
Fauxton as a separate step.
If feasible (in licensing and technical terms), I only offer this as a
stop-gap measure, probably to be coupled with the "install Fauxton" link
option described below in #3.
-- Jonathan
On 08/19/2017 12:50 PM, Jan Lehnardt wrote:
Thanks for getting the ball rolling Joan,
If you are interested in the licensing/policy details, I’ve summed things up on
my blog:
http://writing.jan.io/2017/08/19/understanding-the-facebook-vs-asf-license-kerfuffle.html
— if you want to comment on this, please start a new thread, or email me
privately. This thread is only for what we do next with Fauxton.
* * *
To take a bit of pressure out of this decision making process, I want to bring
up an option that unblocks us indefinitely for making new releases at the
expense of end-user experience.
It’s a little bit of work, but not as much as anything approaching a rewrite.
1. move apache-fauxton to its own GitHub organisation outside of the ASF
(we can always re-integrate it later)
2. publish release builds as tarballs somewhere on the web.
3. replace /_utils in CouchDB with a custom route that displays a simple web ui
with a button “install Fauxton” that goes away once Fauxton is installed, that
then fetches a Fauxton release tarball from outside the ASF and installs it on
the user system.
There is some infrastructure work to be done, and the added inconvenience for
our end-users is not something I’d like to keep up for long.
But should we decide to take this option (or one like it), it would allow us to
not have to rush with a Fauxton adaptation, or be blocked on releases, or have
no admin UI in a release.
* * *
Garren has already done some experiments with preact[1] (a react-API compatible
rendering library with a compatible license) and has a basic prototype running.
Since we are also using additional React libraries that have no corresponding
equivalent in preact-land, Garren expects to migration work to take 1-2 months
of development time, something I’m not sure we are able to afford at this point.
[1]: https://preactjs.com
* * *
Moving to a library that isn’t React-API compatible would be close to a
complete Fauxton rewrite which would likely take years at our pace, and would
break compatibility with downstream addons (that we know Cloudant are using).
As such, my preference would be to stick with the React-API and find a minimal
replacement for what we need. But I’d like to leave the final decision to the
Fauxton team.
* * *
I’d be happy to help with a recruiting drive to get more folks helping to do
the port.
Best
Jan
—
On 19. Aug 2017, at 02:40, Joan Touzet <woh...@apache.org> wrote:
Hello everyone,
<Joan puts her Apache CouchDB PMC hat on>
I have some difficult news to communicate.
Those of you who are more tuned in to the JavaScript world will be aware
that the Apache Software Foundation (ASF) has placed the so-called "BSD
+ Patents" license that Facebook uses in licensing some of its open
source technologies, such as the popular React library, into "Category
X." This means that we are no longer able to ship React in Apache
CouchDB, nor have it as a build dependency, after August 31, 2017.
Subsequently, we asked Facebook if they would consider changing the
React license to avoid this conflict, as they chose to do for their
RocksDB database. About an hour ago, they publicly announced that this
would not be forthcoming:
https://code.facebook.com/posts/112130496157735/explaining-react-s-license/
This means that we must replace the use of React in Fauxton completely
(with something like Vue or preact), and ship CouchDB without Fauxton
until the former can be completed (or simply not ship until the rewrite
is complete.)
No one in the PMC is suggesting we remove Fauxton completely from
CouchDB either now or in the future - we consider our web UI a defining
feature of the product and would consider a Fauxton-less release of
CouchDB incomplete.
I would like to open the discussion towards the Fauxton rewrite, and
specifically:
* Which replacement library do we like the best? Why?
* Who is willing to step up to lead this change?
* Do you know any good JS devs willing to help us?
Those who are interested in the reasons why this policy decision was
reached by the ASF are encouraged to read the following links:
https://issues.apache.org/jira/browse/LEGAL-303
https://issues.apache.org/jira/browse/LEGAL-319
https://github.com/facebook/react/issues/10191
PLEASE do not devolve this thread into discussion about Facebook's
decision, or why the ASF has made the policy decision that they have;
such discussions lead nowhere, and CouchDB is not in a position to
influence either organisation to change their decisions.
On behalf of the CouchDB PMC,
Joan Touzet
