<div dir="ltr">I think it might be lowercase to stick w/ the official Apple swift 3 guidelines, but definitely agree on some type of extensibility. Currently I've been naming that 'other' in general. With that said, that's kind of why I included a String in my proposal. If we can focus on the actual components of the parser and let users define models as much as possible, then it offloads a lot of our opinions into respective frameworks. In terms of Method, here's how I currently have it for discussion:<br><br>enum Method {<br> case get, post, put, patch<br> case other(String)<br>}<br><br>I think in addition to adding new official methods (I might be wrong here, need to double check) but I believe server/clients can define any method they might want to use between them, so I completely agree with you that whatever we have will definitely need some type of extensibility (whatever we call it) to conform to spec.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 23, 2017 at 12:12 PM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 Mar 2017, at 11:18, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
> some types that I think are pretty unambiguous like HTTPMethod<br class="gmail_msg">
<br class="gmail_msg">
May I ask how that would look like in your opinion? I was thinking about that too, and I find it rather hard to come up with a really good solution.<br class="gmail_msg">
<br class="gmail_msg">
The desirable thing would be an enum, but such can’t be extended in Swift w/o an associated value. Like so<br class="gmail_msg">
<br class="gmail_msg">
enum HTTPMethod {<br class="gmail_msg">
case GET, REPORT, MKCALENDAR, CHECKOUT, …<br class="gmail_msg">
case ExtendedMethod(String)<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
But I think this would be pretty weird for ‘late’ methods and you’d end up with code like<br class="gmail_msg">
<br class="gmail_msg">
switch method {<br class="gmail_msg">
case .get: ...<br class="gmail_msg">
case ExtendedMethod(“PATCH”): ...<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
which will look really weird quickly. New methods do not come around every day, but more often than you might think (note explicit support for arbitrary ones in todays XHR, this used to support only GET/POST, hence the xhr-method header thing).<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
</blockquote></div>