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

[Helge Heß]

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 :-)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20171016/128d5df6/attachment.sig>