<div dir="ltr">Chris and others,<div><br></div><div>I'm excited that we're starting to break out into teams with respective focus. I'd like to throw my hat in the ring for HTTP and WebSockets. I've built Swift implementations of both protocols off of RFC from scratch and I think I have much more context there vs the other core groups. </div><div><br></div><div>Looking forward to continuing working with everyone.<br><br>- Logan</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 1, 2016 at 12:58 PM <<a href="mailto:swift-server-dev-request@swift.org">swift-server-dev-request@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send swift-server-dev mailing list submissions to<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">
<br class="gmail_msg">
To subscribe or unsubscribe via the World Wide Web, visit<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">
or, via email, send a message with subject or body 'help' to<br class="gmail_msg">
<a href="mailto:swift-server-dev-request@swift.org" class="gmail_msg" target="_blank">swift-server-dev-request@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
You can reach the person managing the list at<br class="gmail_msg">
<a href="mailto:swift-server-dev-owner@swift.org" class="gmail_msg" target="_blank">swift-server-dev-owner@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
When replying, please edit your Subject line so it is more specific<br class="gmail_msg">
than "Re: Contents of swift-server-dev digest..."<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Today's Topics:<br class="gmail_msg">
<br class="gmail_msg">
1. Working on the new Internet Application Protocol? (Muse M)<br class="gmail_msg">
2. Re: Working on the new Internet Application Protocol?<br class="gmail_msg">
(Alex Blewitt)<br class="gmail_msg">
3. Re: Dispatch + Blocking Calls (Jean-Daniel)<br class="gmail_msg">
4. Re: Dispatch + Blocking Calls (Darren Mo)<br class="gmail_msg">
5. Re: Posix Module (Helge Heß)<br class="gmail_msg">
6. Re: Sockets API (Helge Heß)<br class="gmail_msg">
7. Server APIs Project - next steps (Chris Bailey)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
----------------------------------------------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 1<br class="gmail_msg">
Date: Tue, 1 Nov 2016 01:10:19 +0800<br class="gmail_msg">
From: Muse M <<a href="mailto:james.lei65@gmail.com" class="gmail_msg" target="_blank">james.lei65@gmail.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Working on the new Internet Application<br class="gmail_msg">
Protocol?<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<<a href="mailto:CAB-Y3Cjs0LK-Eq_86hK1u%2BW0mwJymJFGCNuqmxjWgBS6G6XVog@mail.gmail.com" class="gmail_msg" target="_blank">CAB-Y3Cjs0LK-Eq_86hK1u+W0mwJymJFGCNuqmxjWgBS6G6XVog@mail.gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Are there any plans to create new standard of IAP that design to reduce<br class="gmail_msg">
complexity and improve performance?<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2" rel="noreferrer" class="gmail_msg" target="_blank">http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2</a><br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/54192d76/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/54192d76/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 2<br class="gmail_msg">
Date: Mon, 31 Oct 2016 17:21:48 +0000<br class="gmail_msg">
From: Alex Blewitt <<a href="mailto:alblue@apple.com" class="gmail_msg" target="_blank">alblue@apple.com</a>><br class="gmail_msg">
To: Muse M <<a href="mailto:james.lei65@gmail.com" class="gmail_msg" target="_blank">james.lei65@gmail.com</a>><br class="gmail_msg">
Cc: swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Working on the new Internet<br class="gmail_msg">
Application Protocol?<br class="gmail_msg">
Message-ID: <<a href="mailto:1EEF4EBC-5139-4F16-9FB0-B136C8F73B04@apple.com" class="gmail_msg" target="_blank">1EEF4EBC-5139-4F16-9FB0-B136C8F73B04@apple.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
On 31 Oct 2016, at 17:10, Muse M 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">
><br class="gmail_msg">
> Are there any plans to create new standard of IAP that design to reduce complexity and improve performance?<br class="gmail_msg">
><br class="gmail_msg">
> <a href="http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2" rel="noreferrer" class="gmail_msg" target="_blank">http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2</a> <<a href="http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2" rel="noreferrer" class="gmail_msg" target="_blank">http://tutorials.jenkov.com/iap/why-http2-and-websockets-are-not-enough.html#websockets-and-http2</a>><br class="gmail_msg">
<br class="gmail_msg">
I think the initial focus is likely to be on those protocols that are currently being used by other languages and environments, to bring parity in the implementation. These will build upon low level sockets and/or TCP and UDP streams, which would be necessary to contemplate implementing higher level protocols that aren't derivatives of HTTP.<br class="gmail_msg">
<br class="gmail_msg">
Alex<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/94eb6242/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/94eb6242/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 3<br class="gmail_msg">
Date: Mon, 31 Oct 2016 22:25:17 +0100<br class="gmail_msg">
From: Jean-Daniel <<a href="mailto:dev@xenonium.com" class="gmail_msg" target="_blank">dev@xenonium.com</a>><br class="gmail_msg">
To: Darren Mo <<a href="mailto:darren.mo@me.com" class="gmail_msg" target="_blank">darren.mo@me.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Dispatch + Blocking Calls<br class="gmail_msg">
Message-ID: <<a href="mailto:66CD9AE0-B37A-43B6-9DF6-1C3EDB3FF994@xenonium.com" class="gmail_msg" target="_blank">66CD9AE0-B37A-43B6-9DF6-1C3EDB3FF994@xenonium.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> Le 31 oct. 2016 à 09:21, Darren Mo via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> a écrit :<br class="gmail_msg">
><br class="gmail_msg">
> Something to keep in mind… once SR-2905 <<a href="https://bugs.swift.org/browse/SR-2905" rel="noreferrer" class="gmail_msg" target="_blank">https://bugs.swift.org/browse/SR-2905</a>> is resolved, it will be feasible to write Linux server applications in a synchronous manner.<br class="gmail_msg">
><br class="gmail_msg">
> How does this work? Dispatch work items are scheduled onto a pool of kernel threads. If a work item makes a blocking system call, the kernel thread will be blocked. Ideally, the work item scheduler will start a new kernel thread to take the place of the blocked thread. This is only possible if the scheduler can be triggered at the moment the blocking system call is made. A Linux kernel module is required for this to work in Swift.<br class="gmail_msg">
><br class="gmail_msg">
> This ideal threading model is the main selling point of Go. Go developers can write their code in a synchronous manner without any performance tradeoff. (You might be wondering why Go does not need a kernel module. The reason is all the system calls go through the Go runtime before reaching the kernel.)<br class="gmail_msg">
<br class="gmail_msg">
The main benefit of GCD and worker threads is that as the threads are managed by the kernel, it can accommodate thread allocation and io scheduling by considering the system load as a whole, and not only the process load.<br class="gmail_msg">
I’m not familiar with go enough to know how the runtime cope with this, but from the description it look like it don't care about other processes when it managed goroutines.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/9091c27e/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/9091c27e/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 4<br class="gmail_msg">
Date: Mon, 31 Oct 2016 21:55:32 -0700<br class="gmail_msg">
From: Darren Mo <<a href="mailto:darren.mo@me.com" class="gmail_msg" target="_blank">darren.mo@me.com</a>><br class="gmail_msg">
To: Jean-Daniel <<a href="mailto:dev@xenonium.com" class="gmail_msg" target="_blank">dev@xenonium.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Dispatch + Blocking Calls<br class="gmail_msg">
Message-ID: <<a href="mailto:0DEADE51-DE48-4728-8767-7BF5E57209F3@me.com" class="gmail_msg" target="_blank">0DEADE51-DE48-4728-8767-7BF5E57209F3@me.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
You are right that the Go runtime does not care about system load. I suppose it was designed for server applications running in Docker containers or virtual machines. In this world, system load does not matter because a chunk of system resources will be allocated exclusively to the application.<br class="gmail_msg">
<br class="gmail_msg">
> On Oct 31, 2016, at 2:25 PM, Jean-Daniel <<a href="mailto:dev@xenonium.com" class="gmail_msg" target="_blank">dev@xenonium.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> Le 31 oct. 2016 à 09:21, Darren Mo via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> a écrit :<br class="gmail_msg">
>><br class="gmail_msg">
>> Something to keep in mind… once SR-2905 is resolved, it will be feasible to write Linux server applications in a synchronous manner.<br class="gmail_msg">
>><br class="gmail_msg">
>> How does this work? Dispatch work items are scheduled onto a pool of kernel threads. If a work item makes a blocking system call, the kernel thread will be blocked. Ideally, the work item scheduler will start a new kernel thread to take the place of the blocked thread. This is only possible if the scheduler can be triggered at the moment the blocking system call is made. A Linux kernel module is required for this to work in Swift.<br class="gmail_msg">
>><br class="gmail_msg">
>> This ideal threading model is the main selling point of Go. Go developers can write their code in a synchronous manner without any performance tradeoff. (You might be wondering why Go does not need a kernel module. The reason is all the system calls go through the Go runtime before reaching the kernel.)<br class="gmail_msg">
><br class="gmail_msg">
> The main benefit of GCD and worker threads is that as the threads are managed by the kernel, it can accommodate thread allocation and io scheduling by considering the system load as a whole, and not only the process load.<br class="gmail_msg">
> I’m not familiar with go enough to know how the runtime cope with this, but from the description it look like it don't care about other processes when it managed goroutines.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/c8887906/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161031/c8887906/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 5<br class="gmail_msg">
Date: Tue, 1 Nov 2016 11:41:31 +0100<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Posix Module<br class="gmail_msg">
Message-ID: <<a href="mailto:1B21A3EA-AC6A-4B77-A312-6209D13AE5FC@helgehess.eu" class="gmail_msg" target="_blank">1B21A3EA-AC6A-4B77-A312-6209D13AE5FC@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi Johannes,<br class="gmail_msg">
<br class="gmail_msg">
On 31 Oct 2016, at 10:36, Johannes Weiß <<a href="mailto:johannesweiss@apple.com" class="gmail_msg" target="_blank">johannesweiss@apple.com</a>> wrote:<br class="gmail_msg">
>> All I :-) ask for is that those Posix or C99 funds are exposed under a common name whether on Linux, Darwin, Windoze or BeOS.<br class="gmail_msg">
> Understood but that topic is already covered on swift-evolution.<br class="gmail_msg">
<br class="gmail_msg">
OK, great.<br class="gmail_msg">
<br class="gmail_msg">
> I'm more interested in making those functions usable correctly in Swift. Right now, "hard-to-use function" is an understatement IMHO<br class="gmail_msg">
<br class="gmail_msg">
IMHO you are exaggerating quite a bit, but OK :-)<br class="gmail_msg">
<br class="gmail_msg">
>> It probably is, so are sockets, encryption and database access :-) I think you need to start somewhere, and Swift Server is the one place which has to deal with this specific issue right now.<br class="gmail_msg">
><br class="gmail_msg">
> Not sure if I fully agree. I see two areas here:<br class="gmail_msg">
><br class="gmail_msg">
> 1) making the basic OS functionality available to Swift. IMHO that covers being able to call the OS's syscalls and being able to deal with the errors in a robust way. That for me belongs to swift-evolution but this work group could for example come up with proposals.<br class="gmail_msg">
<br class="gmail_msg">
OK.<br class="gmail_msg">
<br class="gmail_msg">
> 2) building libraries on top of these basic primitives. There's a bit more opinion involved here on how to do things. For example obvious questions about the programming model depending if based on Dispatch (DisptchIO or DispatchSource), one of the CSP libraries (eg. lib{dill, mill, venice}), blocking IO ;), or something else. But we should try to not bake too much opinion in these basic building blocks because that might make them incompatible with layers further up (like Zewo, Vapor, Kitura).<br class="gmail_msg">
<br class="gmail_msg">
I think I completely agree with this. As mentioned I also think that this means it would be so low level, it essentially is little more than 'making the basic OS functionality available to Swift’. Similar to what has been done to CoreGraphics or GCD APIs.<br class="gmail_msg">
<br class="gmail_msg">
Presumably something everyone is fighting with is TLS, primarily due to the ‘nice’ API of the relevant library :-) Having a nice Swift TLS API which doesn’t tie into specific transports would be really great (actually having one for C would be great too :-).<br class="gmail_msg">
<br class="gmail_msg">
> Also we have to consider here that right now DispatchIO/DispatchSource is probably a reasonable place to start as Dispatch comes with Swift and a Swift API. But when (in maybe 1.5+ years) Swift gains a memory and concurrency model, Dispatch might not be the best way of doing things anymore.<br class="gmail_msg">
<br class="gmail_msg">
I was wondering about this as well. It may not make sense to invest too much into modelling something bigger when such language changes are on the horizon?<br class="gmail_msg">
Don’t know, interested to see what people come up with :-)<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
A non-text attachment was scrubbed...<br class="gmail_msg">
Name: signature.asc<br class="gmail_msg">
Type: application/pgp-signature<br class="gmail_msg">
Size: 842 bytes<br class="gmail_msg">
Desc: Message signed with OpenPGP using GPGMail<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/88d36fcc/attachment-0001.sig" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/88d36fcc/attachment-0001.sig</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 6<br class="gmail_msg">
Date: Tue, 1 Nov 2016 11:48:58 +0100<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Sockets API<br class="gmail_msg">
Message-ID: <<a href="mailto:F094D362-ECC4-40E4-A9ED-5593A17FFFE6@helgehess.eu" class="gmail_msg" target="_blank">F094D362-ECC4-40E4-A9ED-5593A17FFFE6@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi Daniel,<br class="gmail_msg">
<br class="gmail_msg">
On 31 Oct 2016, at 02:55, Daniel A. Steffen <<a href="mailto:dsteffen@apple.com" class="gmail_msg" target="_blank">dsteffen@apple.com</a>> wrote:<br class="gmail_msg">
> 2) dispatch_io: this is a asynchronous IO facility built on top of dispatch sources (and advisory reads for disk IO)<br class="gmail_msg">
><br class="gmail_msg">
> I can easily believe that 2) might be too high level/abstracted and missing functionality for a server networking framework esp. around encryption (that is not what it was designed for)<br class="gmail_msg">
<br class="gmail_msg">
you are the second one mentioning issues with ‘encryption’. I think I may be missing something here :-) What is the issue with layering TLS on top of channels?<br class="gmail_msg">
<br class="gmail_msg">
Is it an actual issue with TLS/encryption itself or is all that ‘just' because integration with OpenSSL is harder?<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
A non-text attachment was scrubbed...<br class="gmail_msg">
Name: signature.asc<br class="gmail_msg">
Type: application/pgp-signature<br class="gmail_msg">
Size: 842 bytes<br class="gmail_msg">
Desc: Message signed with OpenPGP using GPGMail<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/b9c49d55/attachment-0001.sig" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/b9c49d55/attachment-0001.sig</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 7<br class="gmail_msg">
Date: Tue, 1 Nov 2016 16:11:03 +0000<br class="gmail_msg">
From: Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" class="gmail_msg" target="_blank">BAILEYC@uk.ibm.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Cc: <a href="mailto:swift-corelibs-dev@swift.org" class="gmail_msg" target="_blank">swift-corelibs-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Server APIs Project - next steps<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<<a href="mailto:OFC54DB5E9.98F986FF-ON8025805E.00581636-8025805E.0058E6F0@notes.na.collabserv.com" class="gmail_msg" target="_blank">OFC54DB5E9.98F986FF-ON8025805E.00581636-8025805E.0058E6F0@notes.na.collabserv.com</a>><br class="gmail_msg">
<br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Since announcing the Server APIs project and work group only one week ago<br class="gmail_msg">
we seen a considerable amount of early interest. There are now over 30<br class="gmail_msg">
people signed up in addition to the steering team, and some health<br class="gmail_msg">
discussion has started on the mailing list.<br class="gmail_msg">
<br class="gmail_msg">
One question that's been raised more than once is: Ok, there's a project<br class="gmail_msg">
page and a work group, but what happens next?<br class="gmail_msg">
<br class="gmail_msg">
The Server APIs Project pages outlined three initial focus areas: Base<br class="gmail_msg">
Networking, Security and Encryption, and HTTP and WebSockets. For each of<br class="gmail_msg">
these areas we'll be forming a sub-team whose initial task is to building<br class="gmail_msg">
a Swift Evolution "Pitch". This means collating requirements from the<br class="gmail_msg">
community around function, capability, and usage models, alongside<br class="gmail_msg">
evaluating available technologies like C libraries that could be used to<br class="gmail_msg">
help implement low level function, or existing Swift packages that ideas<br class="gmail_msg">
could be borrowed from, to form a high level sketch of the capabilities<br class="gmail_msg">
that the APIs would implement and an overview of how they would be<br class="gmail_msg">
implemented. Based on feedback from the community, the iterative process<br class="gmail_msg">
of prototyping and development can then begin. The Development Process is<br class="gmail_msg">
documented in more detail on the Server APIs Project page on Swift.org.<br class="gmail_msg">
<br class="gmail_msg">
Over the next few days we'll start to schedule kick-off meetings for each<br class="gmail_msg">
of the sub-teams. We'll be using Doodle polls to try to schedule a time<br class="gmail_msg">
that works for most participants. Obviously what ever day/time it ends up<br class="gmail_msg">
being, there will be some people that cannot make it - don't worry though,<br class="gmail_msg">
we'll be publishing the agenda (along with a request for agenda items) and<br class="gmail_msg">
a full set of minutes on GitHub.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Chris<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/6498680f/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161101/6498680f/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<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">
<br class="gmail_msg">
<br class="gmail_msg">
End of swift-server-dev Digest, Vol 2, Issue 1<br class="gmail_msg">
**********************************************<br class="gmail_msg">
</blockquote></div>