[swift-server-dev] Thoughts on the current HTTP API

[Sergo Bero]

> On 16. Oct 2017, at 18:01, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> This mail can be kinda skipped and is only for those w/ spare time, it doesn’t add much to the discussion :-)
> 
> 
> On Oct 16, 2017, at 5:41 PM, Johannes Weiß <johannesweiss at apple.com> wrote:
>>> The important point is that the thing you need in the end is always a buffer, or better iovec. ‘Producing bytes on the fly’ is what you usually want to avoid as much as possible, IMO.
>>> Instead you want direct and stable access to storage buffers backing the objects. (Which Swift unfortunately does not provide in the stdlib.)
>> 
>> The main point is when writing Strings. There is no contiguously stored UTF-8 buffer but with "some string".utf8 we get an UTF8View which produces the bytes when needed.
> 
> Well, this is kinda incorrect. Correct is ‘there is not *always*’ a contiguously stored UTF-8 buffer. Quite often (a hell lot of time) there is (should be) one, but Swift hides the fact.
> This is essentially my complaint :-)
> 
> 
>>> Don’t know, I personally think it is overkill and I’m good w/ DispatchData. With the exception that I’d like to have API to get an iovec out of a DispatchData stack (instead of just the enumeration method we have now).
>> 
>> yeah, a while ago I filed
>> 
>> https://bugs.swift.org/browse/SR-5143
>> https://bugs.swift.org/browse/SR-5144
>> 
>> about it not being possible (in a guaranteed safe way) to use writev from [Data]/[[UInt8]]/DispatchData.
> 
> Nice.
> 
> 
>>> So what would
>>> 
>>> `func writeBody<Bytes: Collection>(_ data: Bytes, …)`
>>> 
>>> do? Presumably a malloc(), memcpy(from: data).
>> 
>> well, that needs to happen somewhere. You can do it before passing it to the library or within.
> 
> Same like above. It needs to happen somewhere w/ the current Swift stdlib because you can’t get access to underlying buffers, which are usually already there and wouldn’t need to be copied.
> But: ¯\_(ツ)_/¯
> 
> 
>>> (Especially if protocol calls imply a malloc, how crazy is that :palmface:)
>> (only if the actual implementation's type is > 3 words (in Swift 4).)
> 
> I’m still a little flabbergasted that this was ever in, but sure, no need to complain about the past :-)

It was described on last years ( 2016 ) WWDC, Session 416 https://developer.apple.com/videos/play/wwdc2016/416/  Section "The Existential Container” 

> 
> Now if they would fix the malloc when converting between cString and String …
> 
> 
>>> But introducing explicit buffering for just that case, don’t know. Maybe. I guess +0.5.
>> not saying we have to have it but I thought it might be worth bringing that up.
> 
> Sure, thanks, didn’t think of that.
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev