Additionally, before exposing these to the API, a WakeLockDelegate should be exposed and not the WakeLockProvider directly or the WakeLockProvider should be structured and named like the other delegates. In either case, NoOpWakeLockProvider should be probably renamed to DefaultWakeLockDelegate like the other delegates.

@mrobinson how to know the methods to be implemented in the WakeLockDelegate other than the WakeLockProvider?
Thanks

Additionally, before exposing these to the API, a WakeLockDelegate should be exposed and not the WakeLockProvider directly or the WakeLockProvider should be structured and named like the other delegates. In either case, NoOpWakeLockProvider should be probably renamed to DefaultWakeLockDelegate like the other delegates.

@mrobinson Actually, I'm not sure if these changes make sense here. The wakelock implementation is a bit different, because the acquire/release operations from the trait take place after the embedder has already approved or denied the request. The trait represents a platform/hardware-specific abstraction over the wakelock feature, and I don't know if changing the naming to match the Delegate concept we use in the embedder API makes sense.

@mrobinson Actually, I'm not sure if these changes make sense here. The wakelock implementation is a bit different, because the acquire/release operations from the trait take place after the embedder has already approved or denied the request. The trait represents a platform/hardware-specific abstraction over the wakelock feature, and I don't know if changing the naming to match the Delegate concept we use in the embedder API makes sense.

Is the idea that the WakeLockProvider will be exposed to the embedder? If not, I agree it doesn't matter too much what we call it. It does seem like we want to expose this kind of flexibility to the embedder, even if we have a default implementation like we do with the clipboard.

If it will be exposed though, it seems very similar to the GamepadProvider which serves as glue between libservo and the platform's hardware interface. If these things aren't called Delegates, what should they be called and how should we explain the distinction between what should be a Delegate and what should be the other thing?

Fair enough, assuming you're talking about GamepadDelegate. I think that's a useful comparison.

Fair enough, assuming you're talking about GamepadDelegate. I think that's a useful comparison.

Heh. Oh yeah. I meant the GamepadDelegate. If we end up having many of these kind of delegates though, perhaps it would make sense to consider some other kind of API design to organize them all or to place them into some kind of combined platform integration data structure.

Overall this kind of platform specific implementations could be grouped under a "Platform Abstraction Layer" umbrella. What you put here and not, and what makes sense to override by embedders is not always obvious.

For WakeLocks I have a hard time thinking that an embedder could need to override the default platform implementation. On the other hand, something like geolocation has valid use cases for custom implementations.
We don't allow customization of the WebBluetooth platform specific code, but we do for Clipboard and Gamepad... we are already inconsistent!

If we don't want the Servo struct builder itself to end up with lots of configuration options, we could group them all under a PAL trait with a default implementation, and let embedders change any of them. The main drawback would be the increase of public API surface.

There is already prior art in this area as well: https://webkit.org/wpe/

so finally the moving of wakelock trait to embedder_trait would be work done for constellation, for the exposing part a new wake_lock_delegate.rs will be added! is this ok @mrobinson, @jdm?