You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(several edits since I first posted, all before any feedback)
I'm working on the typings for embedded:network/websocket/client, but it quickly devolves into needing to flush out other types. I have a few observations/questions, and likely will have more later, so it seemed appropriate to start a discussion.
Observations so far:
The onControl interface is inconsistent with the ECMA-419 specification, as the implementation is returning a Uint8Array but the specification says it should be ArrayBuffer. Personally, I would much prefer Uint8Array as the data is more immediately accessible, but it is inconsistent with ECMA-419.
The ECMA-419 spec says there should be a network.ws.client and network.wss.client with options on the "Host provider instance" (device) but they are currently missing. I'm also confused why there is a default.network.wss.io with the constructor, whereas other uses are more like default.WS for the constructor (or perhaps default.network.WS?).
The spec for onReadable says there is an optional options parameter. I feel this parameter is important websockets (it has binary and more), but it is not currently implemented. This is likely going to be a high-priority adjustment to the implementation.
I'm fuzzy on the overall typing strategy for device. I see it is partially defined in embedded:provider/builtin. The two strategies I can see are to define everything in embedded_provider (and using optional parameters when not all implementations will provide it or import it), or have the individual imports extend device (which isn't straight-forward currently with how typings are imported in manifest.json). There are extra complexities, such as the DNS resolver type is for the UDP resolver, but when DNS over HTTP is available the Options type becomes a union of options. My gut is to define them all in embedded:provider/builtin.
Currently you must import device from embedded:provider/builtin to get the types, but device itself is injected into the global namespace. ECMA-419 makes global optional, but requires the import to be available. Shuld device types available in global types, or require the import on TypeScript implementations?
In general, I recommend all options types be given unique names and be exported as they need to be consumed by other type implementations.
I'm unclear on the line between core io modules and those in examples, and how that might relate to types - being always defined in types, or only when imported (and therefore, extending existing types). Do we just treat modules in examples as being full modules in core io types?
I've also noticed that some io implementations do not use the embedded:xxx namespace, and at least some do not conform to the 2nd ECMA-419 spec. For example, sntp, which I was going to use but fell back on the legacy version for now since it didn't seem current. Am I correct in assuming that if they are not part of embedded: that we just ignore them for now?
I've not yet implemented types for the WebSocket close codes, partially because I find using read to receive a close code/reason and leaving the decoding of the message to the consumer an unusual approach to handling close codes. It puts the burden on the API consumer to understand the message format and proper handling of the close process (for example, the initial sender of a close must wait for confirmation of the close, but only if the close code is a network-enabled code). This may be a place for the specification to improve.
It would be nice if the onError event was implemented to provide an error property. The implementations commonly use a string for the error parameter (not an Error object). Is there a standard for onError for consistency of use?
Draft of `embedded:network/websocket/client` (assumes some changes to other types)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(several edits since I first posted, all before any feedback)
I'm working on the typings for
embedded:network/websocket/client
, but it quickly devolves into needing to flush out other types. I have a few observations/questions, and likely will have more later, so it seemed appropriate to start a discussion.Observations so far:
onControl
interface is inconsistent with the ECMA-419 specification, as the implementation is returning aUint8Array
but the specification says it should beArrayBuffer
. Personally, I would much preferUint8Array
as the data is more immediately accessible, but it is inconsistent with ECMA-419.network.ws.client
andnetwork.wss.client
with options on the "Host provider instance" (device
) but they are currently missing. I'm also confused why there is adefault.network.wss.io
with the constructor, whereas other uses are more likedefault.WS
for the constructor (or perhapsdefault.network.WS
?).onReadable
says there is an optionaloptions
parameter. I feel this parameter is important websockets (it hasbinary
andmore
), but it is not currently implemented. This is likely going to be a high-priority adjustment to the implementation.device
. I see it is partially defined inembedded:provider/builtin
. The two strategies I can see are to define everything inembedded_provider
(and using optional parameters when not all implementations will provide it or import it), or have the individual imports extenddevice
(which isn't straight-forward currently with how typings are imported inmanifest.json
). There are extra complexities, such as the DNS resolver type is for the UDP resolver, but when DNS over HTTP is available the Options type becomes a union of options. My gut is to define them all inembedded:provider/builtin
.device
fromembedded:provider/builtin
to get the types, butdevice
itself is injected into the global namespace. ECMA-419 makes global optional, but requires the import to be available. Shulddevice
types available in global types, or require the import on TypeScript implementations?io
modules and those inexamples
, and how that might relate to types - being always defined in types, or only when imported (and therefore, extending existing types). Do we just treat modules inexamples
as being full modules in coreio
types?io
implementations do not use theembedded:xxx
namespace, and at least some do not conform to the 2nd ECMA-419 spec. For example,sntp
, which I was going to use but fell back on the legacy version for now since it didn't seem current. Am I correct in assuming that if they are not part ofembedded:
that we just ignore them for now?read
to receive a close code/reason and leaving the decoding of the message to the consumer an unusual approach to handling close codes. It puts the burden on the API consumer to understand the message format and proper handling of the close process (for example, the initial sender of a close must wait for confirmation of the close, but only if the close code is a network-enabled code). This may be a place for the specification to improve.onError
event was implemented to provide an error property. The implementations commonly use a string for the error parameter (not anError
object). Is there a standard foronError
for consistency of use?Draft of `embedded:network/websocket/client` (assumes some changes to other types)
Beta Was this translation helpful? Give feedback.
All reactions