Clarifying the subset strategy

[memeplex]

A subset strategy limiting existing APIs to subsets supported across versions is detailed in https://github.com/microsoft/WindowsAppSDK/blob/main/docs/README.md#subset-api-family. There is also a suggestion to ask for additional subsets by reporting an issue with the tag subset, but this label doesn't exist in the tracker and I'm unable to find any issue that's a clear example of the subset strategy.

Now, is this intended to cover most of Windows APIs in advance or just very specific selected portions, incrementally and on demand? What has been done in this regard? For example, the reference for Win32 in the Windows App SDK documentation shows very little, nothing like extensive coverage of parts supported across Windows versions.

Thanks!

[ghost]

@andrewleader can you please forward the question to someone who can clarify the very readme section ? reading through the readme again and again didn't help. things like, which subset apis will be supported and which won't be ?
why "subset apis" issue making are needed ? etc

[andrewleader]

Hi @memeplex, thanks for asking this! The "subset" section of our README is a bit outdated. It's still a "proposal".

However, there are some examples of "subsets" of APIs that were brought to Windows App SDK though. The best example is WinUI 3. WinUI 3 is essentially exactly the same API surface as inbox UWP WinUI. Switching to WinUI 3 mostly just involves switching using statements from Windows.UI.* to Microsoft.UI.*. Thus, the entire subset of WinUI APIs from the Windows SDK were brought to the Windows App SDK.

We could consider doing the same with other sets of APIs. For example, we could do the same with the StorageFile/StorageFolder family of APIs, bring those over to the Windows App SDK as-is, and then "switching" to them is just a simple namespace update.

If you have any suggestions of APIs you'd like to see brought over as-is, or want to share any feedback on whether you think this is or is not a good idea, please let us know! Thanks!

And we'll work on updating that docs README sometime, it hasn't been touched in a while.

[memeplex]

Thanks for taking the time to answer!

I see your point regarding WinUI, in that it's a subset of Windows SDK, but according to https://github.com/microsoft/WindowsAppSDK/blob/main/docs/README.md I would have put it into the "Converged API" category since it's

bridg[ing] the gap between Win32 and UWP/AppContainer

and not

help[ing] you stay within the set of APIs that Windows supports on all editions and all endpoints

One thing that's not clear to me is that if the "Subset API Family" is intended to cover big chunks of existing APIs then wouldn't that be in tension with the reunion goal of being incremental, additive and not a new app model? It's a thin line, but if you cover 95% of existing APIs then it feels like a new app model to me, one that's mostly conservative but still... What do you think?

[memeplex]

This is more or less as I understand the different strategies:

API A      API B        Reunion
----------------------------------
no         no           new
yes        no           converged
no         yes          converged
yes        yes          subset

wouldn't that be in tension with the reunion goal of being incremental, additive and not a new app model?

I'd like to make this more precise. Suppose that the subset case is about 99% of app models A and B and a new model C emerges. Then it either:

• Implements this subset
• Doesn't implement it, but should support addition of it as a now converged (since it's not in C) API

Both options are overly restrictive on a new API, specially if it's a new app model. True, it's not probable that a new app model will emerge in the near future. But, at least conceptually, going too far in the subset direction seems like trying to define an uber app model.

[andrewleader]

Great feedback. Over many years, we might get closer to covering 95% of existing APIs, but that's not the explicit goal, our overall goals are...

1. Make our APIs (that people are interested in using) available to all types of apps (most commonly, making them usable by unpackaged desktop apps like WPF)
2. "Undock" our APIs over time so they're shipped out-of-band, meaning we can update and fix problems without requiring an OS update, and so that you can use new features without waiting for your users to update their PCs
3. Typically try to add any new APIs via WinAppSDK rather than the Windows SDK (so that they're instantly usable, not dependent on the OS, can be updated faster, etc).

Both 1 and 2 require creating a new set of APIs. That set of APIs might have the same API structure but a new namespace, or the APIs might also change their shape and form, but they need to be a new set of APIs to be undocked (shipped in something different) and to add support for all types of apps.

However, there are already some APIs that work for all types of apps. And unless those APIs have high levels of change and high levels of bugs, it's probably not worth moving those APIs to WinAppSDK. Don't change what isn't broken 😊

So to provide a table to try to help understanding, I'll use concrete examples...

API set	Works for WPF/unpackaged/etc?	Action
WinUI	No	Port existing Windows.UI.Xaml APIs to WinAppSDK Microsoft.UI.Xaml and make the APIs usable by all types
Push notifications	Doesn't support unpackaged	Make a new API in WinAppSDK that works for all types, new API structure is needed to also decouple from Store identity (common feature request from developers)
File pickers	WPF has their own, etc	Potentially create a new API that's converged and works across all

Hope that helps some!

[ghost]

@memeplex representation of what is logically implied there.
@andrewleader is it near correct ?

[ghost]

Reunion will eventually provide a subset of Win32 APIs plus a set of Reunion-specific new functionality. These APIs are those that Reunion can help you run everywhere (Desktop, HoloLens, Xbox, Surface). there will be some "Classic Desktop" APIs that are not brought to Reunion, but you can still use them by "reaching through" Reunion's partition out to the Windows Kit.
#15 (comment)

as per @jonwis' comment I suspect Yes.