[swift-server-dev] Prototype of the discussed HTTP API Spec

[Paulo Faria]

 > I mean, having buffers don't make async APIs impossible.

Having raw buffers instead of DispatchData.

On 26 May 2017 at 21:05, Paulo Faria <paulo at zewo.io> wrote:

> > In a synchronous setup you usually ‘receive’ (and send) directly into a
> buffer and may not even need to allocate it on the heap. In a asynchronous
> setup you have to allocate it on the heap, because -  well, the
> reference/buffer needs to stay until the receive is completed. Well, and,
> DispatchData is a heap object optimized for that. Though I don’t know why
> this isn’t integrated with Data.
>
> What I mean is.. Nothing is stopping one to hold the reference to the
> buffer, right? I mean, having buffers don't make async APIs impossible.
>
> On 26 May 2017 at 20:54, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
>> On May 27, 2017, at 1:19 AM, Paulo Faria <paulo at zewo.io> wrote:
>> > I'm not sure I follow your example. Cat.Animal doesn't make much sense
>> to me while Animal.Cat makes perfect sense.
>>
>> Precisely. Name it after the concrete thing, not after the abstract
>> concept.
>>
>> > When importing HTTP you know you'll deal with HTTP requests and not
>> anything else.
>>
>> HTTP servers don’t exist in the void. Your endpoint is going to do
>> something, e.g. some other form of request. In the case of HTTP application
>> servers this is going to be quite often an: NSFetchRequest ... well, a
>> CoreData.Query.Request in your API naming convention …
>>
>> But we can leave it at that. If people think that this is a good idea, go
>> ahead. I recommend against it.
>>
>> > most of the APIs are synchronous
>>
>> If you say so. I notice exactly the reverse ;-) Most of the API in
>> Node.js is async for sure and good reason.
>>
>> > > For async you usually need some way to hold on to a buffer, and that
>> is DispatchData
>> >
>> > Sorry can you elucidate that? If you have the pointer, you're holding
>> the buffer aren't you? I'm not sure I follow the issue.
>>
>> In a synchronous setup you usually ‘receive’ (and send) directly into a
>> buffer and may not even need to allocate it on the heap. In a asynchronous
>> setup you have to allocate it on the heap, because -  well, the
>> reference/buffer needs to stay until the receive is completed. Well, and,
>> DispatchData is a heap object optimized for that. Though I don’t know why
>> this isn’t integrated with Data.
>>
>> hh
>>
>>
>> >
>> >
>> > On 26 May 2017 at 20:09, Helge Heß via swift-server-dev <
>> swift-server-dev at swift.org> wrote:
>> > On May 27, 2017, at 12:55 AM, Paulo Faria <paulo at zewo.io> wrote:
>> > > Helge! I agree with most of your suggestions and I'll update my
>> proposal with them. There's only one I'm not with you and it's about the
>> HTTP prefix. The example you mentioned could be easily solved by adding
>> `HTTP.` when referring to the specific type.
>> > >
>> > > import HTTP
>> > > import SOAP
>> > >
>> > > let request = HTTP.Request()
>> > >
>> > > We have used Request and Response without prefixes for about two
>> years and not once anyone complained about that. I imagine others who use
>> the same naming scheme can testify to that.
>> >
>> > Having seen such overloading in Java frameworks before I simply
>> disagree with that. The object in question is plainly a HTTPRequest(Head)
>> not just some arbitrary request. The ‘HTTP’ really is part of the thing. In
>> fact the ‘arbitrary’ request could be an NSOperation, providing
>> functionalities such as pause, cancel, etc.
>> >
>> > In a way it is like
>> >
>> >   import Cat
>> >
>> >   let pet = Animal() // resolving to Cat.Animal()
>> >
>> > But well, if people really like that … ;-) I vote against it.
>> >
>> > > About Sync/Async prefix. I was talking about type prefixes not method
>> prefixes. We definitely shouldn't prefix function APIs with sync or async.
>> I honestly don't care too much about which one to use as a default. I just
>> think it makes more sense to prefix the Async ones.
>> >
>> > Your particular setup is sync, right? ;->
>> >
>> > > About raw buffers we could provide APIs that take an array of
>> Unsafe[Mutable]RawBufferPointer to pass them to readv, writev and
>> company. Those could also be easily converted to DispatchData in the
>> frameworks that prefer to use it.
>> >
>> > This is a little related to sync vs async. For async you usually need
>> some way to hold on to a buffer, and that is DispatchData. For sync you
>> usually don’t have to, and pointers to buffers can be faster.
>> >
>> > Though I do think that sync is more appropriate for many server
>> builders, I think that the goal for Swift-Server would be more oriented
>> towards async. I may be wrong.
>> >
>> > hh
>> >
>> >
>> > _______________________________________________
>> > swift-server-dev mailing list
>> > swift-server-dev at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>> >
>> >
>>
>>
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170526/634c517d/attachment.html>