Reviews are an important part of the Swift Server Work Group incubation process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email or direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, become listed on the Swift Server Ecosystem index page.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal and its APIs/implementation?
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
What is your evaluation of the proposal and its APIs/implementation?
+1
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Multipart formdata is a common format used widely across the server ecosystem. Having a standard package for parsing it should be a target.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes. Its uses Codable for encoding and decoding multipart form data
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I added a sample to the Hummingbird examples repository that demonstrated how to integrate it into a Hummingbird server. Integration was fairly easy. During this process I added a PR to make it easier to work with NIO ByteBuffers.
I have not looked into the internals of the system too much, as it just worked. I did notice it contains a large chunk of the swift-collections codebase and wondered whether that was necessary.
We use it for storing the different boundaries IIRC (@siemensikkema can provide the actual reason). Now that Swift Collections is 1.0 we can pull it in as a dependency instead of copying the code - there's a draft PR up to do that.
*Note: this would require us to bump the minimum supported Swift version of MultipartKit (and therefore Vapor) to 5.3 - I'm not adverse to this but might be worth a discussion
This is a question not a review, sorry if this is the wrong place.
I'm using MultipartKit to generate raw emails with attachments for use with AWS SES. Getting this to work required a lot of trial and error and I ended up having to customize the serialization to get it working correctly.
So is MIME encoding something that should/could be included in this library? When I was working on this, I couldn't find a Swift library that supported it. It seems having it in this library would be a logical place for it and I think it would be a valuable addition. Thanks!
Correct. It is included for OrderedDictionary which ensures a fixed order of the named parts when encoding. I would vote to drop 5.2 support if that means we can just depend on swift-collections.
Yes, 5.2 is part of the test suite of MultipartKit. If there is any real incompatibility of swift-collections with Swift 5.2 then at least it is not in the part I extracted.
Such a library is definitely welcome! I do think the "nesting and collections" decoding/encoding is too rigidly bound to the Ruby on Rails convention. Other languages/frameworks out there use other encodings for nesting and collecting data, so ideally such a strategy would be customizable, similar to the strategies provided to JSONDecoder and JSONEncoder.
We built a URL form decoder a long time ago and these were the strategies we supported:
Haven't visited the above code in awhile, but it'd be great for MultipartKit to support something similar!
I agree that would be a welcome customisation option. Thanks for linking to that snippet. It explains the scenarios very clearly.
The transition to the "RoR convention" was actually a relatively recent change when we were made aware of the limitations of the other approach. Adding the ability to choose a strategy should be a non-breaking change we can introduce later on.