[
https://issues.apache.org/jira/browse/THRIFT-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939048#comment-13939048
]
Randy Abernethy commented on THRIFT-2398:
-----------------------------------------
Hey Pierre,
Great stuff. I agree that we should return a "thrift" object wrapping the
Node.js server. Much better that.
The port thought I agree with as well. The Apache Thrift Node.js lib is
presently very intertwined with the Node.js lib around the end point, client
and server.
I agree on the taxonomy front as well, though some of the things we're talking
about are not only taxonomy but structural convention. Standardized conventions
are a valuable thing, especially in the context of a framework. A great way to
cause your users to create unintentional bugs is to change your conventions
within a lib or framework.
Let's keep working on this stuff. The clear patch I see presently is the server
return improvement, one of us should create a new issue for that. We can keep
thinking about the best way to bring Node.js in line with the Apache Thrift
abstract I/O stack model and push it in the right direction piece by piece.
Best,
Randy
> Improve Node Server Library
> ---------------------------
>
> Key: THRIFT-2398
> URL: https://issues.apache.org/jira/browse/THRIFT-2398
> Project: Thrift
> Issue Type: Improvement
> Components: Node.js - Library
> Affects Versions: 0.9.2
> Environment: all
> Reporter: Randy Abernethy
> Assignee: Randy Abernethy
> Attachments: 0001-nodejs-server-and-option-cleanup.patch,
> 0001-updated-nodejs-hello-example.patch
>
>
> Improve Node Server Library
> =======================
> Background
> ----------------
> In the last 7 months Node.js has gone from one server constructor:
> • createServer()
> to seven, adding:
> • createSSLServer()
> • createMultiplexServer()
> • createMultiplexSSLServer()
> • createHttpServer()
> • createHttpsSSLServer()
> • createWebServer()
> there are really only two implementations:
> • createMultiplexSSLServer()
> • createWebServer()
> Several of these servers have undocumented options and share options objects
> with other libraries.
> Proposal
> -------------
> 1. Remove all of the create signatures except these three:
> o createServer()
> o createMultiplexServer()
> o createWebServer()
> with createServer() implemented by createMultiplexServer(). All signatures
> will support optional multiplexing and optional SSL/TLS. Eliminate no present
> functionality and maintain signature compatibility in the three signatures
> preserved.
> 2. Document and standardize all server options and parameters with notes
> describing any deprecated features being preserved for backward compatibility.
> Motivation
> -------------
> The dispersion of create methods makes it harder for developers to know which
> server to use and leads to diffusion in the way that options and features are
> provided. This also complicates testing. Reducing the servers to the two
> currently supported end point transports (TCP and HTTP) will enforce
> standardization and simplify adoption. Now is the time to address these
> issues before the new create signatures show up in a released version.
> Approach to Options
> ----------------------------
> Presently the non-web server options objects may have transport and protocol
> properties. Undocumented key and cert properties are used to enable the
> options object to be passed to the Node.js tls and https createServer()
> methods. This approach requires Apache Thrift options to be visible to the
> Node.js library methods and vice versa. A better approach might be to place
> Node.js tls options in a tlsOptions object which is itself a property of the
> server options object. This will allow any tlsOptions to be passed through to
> Node.js without concerns for conflicts on the Node.js or Apache Thrift side,
> now or in the future. The presence of a tlsOptions object can also be used to
> enable SSL/TLS in the two server implementations rather than having separate
> functions.
> Would like to know what others think about this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
