May 30th, 2019

Server Workgroup Updates
1

Meeting Notes 30th May 2019

attendance: Ian (@IanPartridge ), Ted (@tkremenek), Tom (@tomerd), Chris (@Chris_Bailey), Tanner (@tanner0101), Logan (@Logan_Wright), Johannes (@johannesweiss)

  • ACTION: Johannes to publish last meeting's notes (done by now)

Docker

  • invite Mishal to next meeting to look into docker images for the Swift nightly builds (for 5.1/master)
  • official images now also in use by some NIO packages & Vapor --> works great (IBM has already previously been using them and Ian is the main contributor so needless to say they work there too :slight_smile:)
  • to be able to switch all NIO repos, we need docker nightlies (because the main NIO repository does test on nightlies today)

Backtraces

  • Ian: made a pitch
    • there are three partial solutions today (see pitch)
  • Ted: possibly we could a better Swift runtime support
  • Ted pointed some folks to the thread
  • Tom: language team to give guidance whether/what should come from the community vs. language
  • Ian: the Nodes backtrace version calls into the private swift runtime API for demangling, is that okay?
  • Ian: we should together the expertise that's there and we should shortly be able get something working short term

HTTP client

  • lots of discussion happening there
  • can we tag 0.0.0?
  • upload/download streaming changes public API, but we're almost there with the patches there
  • should we put public API changes in (and finish streaming later)?
  • decision: we put public API change in, then tag 0.0.1 ASAP
  • NIO2/Swift 5 only (because Vapor 4 will be and Kitura 2.7 is already)

Redis

  • waiting for the namespacing debates to settle
  • in discussion right now, next & final step is the opening of the feedback thread

APNS

  • on track
  • namespacing plays into this as well
  • in feedback, vote ETA: next SSWG meeting

Mongo

  • good the official Mongo driver & MongoKitten came up because we could clarify that there can be more than one solution approved solution in the SSWG. The minimum requirements are what matters not if there is already an existing package.
  • apart from exceptions like logging/metrics APIs: it's totally cool to have more than 1 solution
  • Johannes: one sticking point: is NIO as IO really required or not? Because that's what the minimum requirement say so at the moment
  • Tom: non-blocking API is more important than strictly NIO for IO
  • Logan: minimum non-blocking API important, also sqlite which is file based so can't use NIO to 'communicate' with the DB
  • Tanner: fine if using a thread pool IFF the readme says that it's blocking some kernel threads in the background but needs to be made very clear.
  • Logan: +1, we need to make sure that there's no confusion about which libraries are blocking threads in the background and which ones aren't
  • Logan: non-blocking API should use NIO futures (but thread pool okay)
  • Tanner: callbacks would be annoying, so +1 on Logan
  • ACTION: we need to refine the wording in the minimum requirements around NIO/non-blocking/thread pools/...

Namespaces

  • 2 uniqueness requirements in SwiftPM; 1 in Swift (module names)
  • Tom: talked to SwiftPM, they're open to dicussions
  • Ted: it's even more wide-ranging than packages
  • Tom: Java/Ruby have convention (like Java's reverse DNS)
  • Johannes: apart from the 3 mentioned problems; there's a 4th issue around types introduces in SemVer minor might clash and break software
  • Ted: SemVer doesn't resolve it 100% either
  • we agree SemVer doesn't fully solve it but can help and with the right guidelines solve much of the issue
  • Tom: issue is hitting us already right now already and will get worse, need to find solutions
  • Ted: "this is an inherently under-designed space"
  • Ted: solution needs multiple axes with SwiftPM/language/community guidelines
3 Likes