[Discussion] OpenAPIKit

[mattpolzin (Mathew Polzin)]

On the topic of Dependencies:

@Jon_Shier

@tanner0101

I'm +1 to pulling the min required elements of these into OpenAPIKit itself. Given that this is a very low level package that will be brought into potentially many libraries, keeping this as simple as possible will be a huge win.

I see this requirement by the SSWG as fundamentally at odds with improving the Swift development community, even with a server-side focus.

@Jon_Shier

So perhaps I'm just saying the SSWG should consider incorporating libraries that serve a more basic purpose than "feature" libraries that can have guaranteed versioning and release support.

@GalCohen

On the dependency discussion - there are also other implementations in the community. Worth evaluating them if the route of sticking with dependencies is taken over rolling them in.

I like the idea of the SSWG supporting, nay encouraging adoption of certain implementations of types offering functionality that is needed commonly and perhaps even more so in server-side development than elsewhere.

I also agree that the group should not simply endorse dependencies based on the first time they show up in another library that just happens to be up for proposal. There very well might be better implementations out there and those other implementations may have been missed precisely because it can be difficult to find or decide on third party options outside of the recommendations made by the WG.

Then again, the broader community might be ultimately hurt by a proliferation of bite sized libraries as Tanner points out are the feelings of some in the NodeJS community.

My suggestion would be this: Recommend libraries like OpenAPIKit internalize "building block" dependencies for now, but explicitly plan for WG support of shared common core dependencies to be driven by emerging demand as more libraries are accepted into incubation. Details notwithstanding (and not belonging in this proposal thread), this approach could, for example, allow for a single common core library with different products for each core component instead of wholly separate libraries for each component.

I will start a new thread on the topic of dependencies because I like where this conversation is going but I don't think this proposal is a visible enough place to have the discussion.

On the topic of OpenAPIKit Dependencies:
Aside from code re-use, I am not concerned about the impact of bringing the three necessary dependencies into the library. I think the other primary consideration is interop:

1. AnyCodable is generally used strictly as a type erasing wrapper where there is little utility in carrying an "AnyCodable" around; rather, you put something in to encode it and you take something out to decode it. This reduces the likelihood of confusion or frustration over another library also using AnyCodable (or writing their own version of such a utility).
2. Poly (and specifically the Either type needed by OpenAPIKit) is similarly used as a wrapper type. You might carry an Either value around but ultimately (at least in the context of OpenAPIKit interaction) you are more likely to pull something out of it than you are to be frustrated by it not being the same type as another Either implementation in use. I believe this to be a particularly valid estimation because OpenAPIKit is not a library offering up general utility types.
3. OrderedDictionary aims to offer the same APIs as Dictionary where possible. It is a goal (whether or not fully realized at this stage) that it be easy to create an OrderedDictionary, easy to interact with it directly as a "dictionary type", and also easy to get an Array of key/value pairs back out, which could be used to construct a Dictionary if you did need to pass an OrderedDictionary on to something that did not care about ordering or know about OrderedDictionary.