Short version: I have no objection to making all the modules internal, although I think there is value in the Keyboard module that make it interesting to other people/projects.

Longer version:

My original intention was that each of these modules would be generic enough that others could use them independently. I do think there is value to the maintainability of the project to keep those modules modular and independent of each other module. Documenting the public API of each module was a way of keeping myself honest about that modularity.

However, at this point, I don't think any external projects would be likely use Mouse or Display. There are a lot of projects/frameworks that have similar functionality and the current Mouse and Display modules are somewhat specific to what we need in noVNC. On the other hand, I think all the effort that we have put into the Keyboard module to work around browser limitations and quirks is fairly unique and solves a problem that a number of different types of web applications have (and will continue to have in the future). So I still think there is some value in keeping it documented for possible external use. However, that would require a level of commitment from our team and if none of us want to own that, then we don't want to mislead people into thinking it's something it's not (and then filing bugs that would just be noise for us).

On the topic of RFB module APIs: I recently ran across https://github.com/mikeal/webtorrent-element. I think something like that might be interesting for noVNC as a future feature.

On the topic of RFB module APIs: I recently ran across https://github.com/mikeal/webtorrent-element. I think something like that might be interesting for noVNC as a future feature.

If you are referring to the shadow DOM thing, then yes please. :)
I'm keeping my eye on that an eagerly awaiting when it is rolled out in most browsers.

• Can we try to bring in Properly give focus to canvas #916 before a release? It fixes a number of known issues but changes the API a bit

The API, yes. But the actual code can wait. I don't think it's a regression?

I'd also like to have a look at our properties, making them a bit more standard.

I'll submit a PR with what I'd like to change.

The API, yes. But the actual code can wait. I don't think it's a regression?

Actually, we need this in order to clean up the API. Argh...

Some more issues I've found whilst going over things:

• We don't expose any way to change translations
• We don't expose any way to control logging
• We use strings in the notification and disconnect callbacks, which is generally a bad idea for backend objects like this
• The scaling API is rather complex and probably a bit too specific to how we use it in ui.js. We could consider moving more of the scaling handling in to the RFB object.

If you are referring to the shadow DOM thing, then yes please. :)
I'm keeping my eye on that an eagerly awaiting when it is rolled out in most browsers.

I actually wrote a quick-and-dirty custom element for noVNC a while ago. It worked pretty well. Needed polyfills for Firefox, worked natively in Chrome. Had to do some translation from the noVNC callbacks to the more element-style events, though.

My thoughts (written on #927 as well):

• Do we need all of these public functions?

Probably not, but it's hard to decide. It's a tricky balance between good API surface and too much API surface.

• Are we satisfied with all the names?

Mostly? Can't think of anything off the top of my head, but I do recall a couple of awkward names. Will try and look for some. I like most of the name changes made in the linked PR.

• Use the Event type for our callbacks. More in line with general JavaScript API's. Also, currently with the "onEvent" style we can only have one listener at a time.

Are you suggesting implementing EventTarget (https://developer.mozilla.org/en-US/docs/Web/API/EventTarget) for noVNC? I'm on board with that.

• Can we try to bring in Properly give focus to canvas #916 before a release? It fixes a number of known issues but changes the API a bit

I'll need to look in more detail, but the general gist seems reasonable.

• We don't expose any way to change translations

You mean on the fly in the UI? That would be interesting, but I don't think we need it for 1.0.0

• We don't expose any way to control logging

Huh? That's what core/util/logging.js is for...

• We use strings in the notification and disconnect callbacks, which is generally a bad idea for backend objects like this

Not sure I follow this one. What's the alternative here?. Ah, I see what you mean. Why can't we translate at the user-facing boundary -- use strings internally, and translate anything we have to pass up to the user?

• The scaling API is rather complex and probably a bit too specific to how we use it in ui.js. We could consider moving more of the scaling handling in to the RFB object.

Do you have any specific complaints here?

On keeping the mouse/keyboard/display APIs:

Generally agree with @kanaka -- I don't mind moving more things internal, but keeping keyboard separate would probably be nice.

I do think that keeping a limited external API is nice in terms of separating abstraction though -- I like the division, I just don't think we need to guarantee the entire API (for instance, keep set_scale and friends public, but don't guarantee the internal drawing APIs). For instance, anything that we call from ui.js could stay guaranteed, everything else is considered internal/unstable -- see my comment #927 (review).

Probably not, but it's hard to decide. It's a tricky balance between good API surface and too much API surface.

Indeed. But it's easier to add things than to remove them. So I would prefer if we start with a conservative approach.

Huh? That's what core/util/logging.js is for...

Which is internal, so I think we would need a better interface.

But I think we can live with logging not being configurable for the 1.0 release. We can add something later.

Why can't we translate at the user-facing boundary -- use strings internally, and translate anything we have to pass up to the user?

The user-facing boundary is UI, not RFB. So ideally we should have codes describing states. Otherwise we'll easily end up with people doing string matching on the API...

Do you have any specific complaints here?

Not more than the fact that we have quite a bit of interaction in UI to use these APIs. It suggests to me that we've done the layering wrong. I need to look at it more and give a more tangible suggestion.

One idea is to move towards a shadow DOM approach. We would give the RFB object a container instead of a canvas and it would set up things as it needs to inside that container. The API would then just configure the policy it should apply.

ah, you have a slightly different boundary of "user facing". I think it's allowable to have some stuff that's not in the RFB object be user-facing. Namely, anything that doesn't seem to belong in the RFB object, but is used in app/ and is from core/.

We use strings in the notification and disconnect callbacks, which is generally a bad idea for backend objects like this

I have a PR in the works to adress this issue, stay tuned.

We use strings in the notification and disconnect callbacks, which is generally a bad idea for backend objects like this

See #950

I feel satisfied with the API for now. If someone has anything else they want do discuss or change before a release, please reopen this soon.

I want to make a suggestion to improve scale/resize handling first.

#960 is merged so closing this issue.