You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Randy Abernethy (JIRA)" <ji...@apache.org> on 2014/03/12 03:17:42 UTC

[jira] [Created] (THRIFT-2398) Improve Node Server Library

Randy Abernethy created THRIFT-2398:
---------------------------------------

             Summary: 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


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)