Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-6601

Expose pluggable interface for I/O functions

    • Type: Icon: Epic Epic
    • Resolution: Unresolved
    • Priority: Icon: Unknown Unknown
    • None
    • Affects Version/s: None
    • Component/s: Connection Layer
    • Hide
      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?
      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • To Do
    • Pluggable I/O
    • 0
    • 0
    • 0
    • 100

      Summary

      Developer tools applications have had various needs for being able to customize the driver's I/O functionality, in particular around network connectivity/DNS resolutions. This project aims to provide an API for applications to provide their own implementations of these methods.

      Primarily, this would be about methods currently imported from the net, tls and dns Node.js core packages. Additionally, it may be worth keeping in mind that the web version of Compass provides stubs for other packages, such as fs, http, child_process and zlib in order to be able to run well in a web environment, but where the functionality provided by these packages is currently not critical to core driver functionality.

      The design for this project should take into account how this interacts with existing similar features, such as the optional dependency mechanism (does it make sense to keep these in the form of a try-require-catch?), and how we communicate to users that, if they run into issues when using custom I/O methods, they should first verify that these issues are actually caused by driver logic before reporting them.

      Motivation

      Who is the affected end user?

      Stakeholders for this is primarily devtools. Other applications built on top of the Node.js driver may or may not be able to make use of this functionality as well, and this may allow easier adoption of other runtimes that don't purely rely on Node.js compatibility.

      How does this affect the end user?

      Devtools applications will have an easier time adopting changes in the driver, they may be able to use SRV polling, and it will be easier to improve diagnostics in these situations. They will also be in control of freeing up resources like connections at points in time decided by the application, rather than the driver (at least currently/before NODE-5221).

      How likely is it that this problem or use case will occur?

      Main path for the relevant applications.

      If the problem does occur, what are the consequences and how severe are they?

      N/A

      Is this issue urgent?

      No, although it happens on a regular basis that we'd like to be able to make use of functionality like this.

      Is this ticket required by a downstream team?

      Yes, this targets developer tools use cases.

      Is this ticket only for tests?

      No, it's functional.

      Cast of Characters

      Engineering Lead:
      Document Author:
      POCers:
      Product Owner:
      Program Manager:
      Stakeholders:

      Channels & Docs

      Slack Channel

      [Scope Document|some.url]

      [Technical Design Document|some.url]

            Assignee:
            Unassigned Unassigned
            Reporter:
            anna.henningsen@mongodb.com Anna Henningsen
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: