Update doap with support for XEP:0483 - HTTP Online Meetings via olme…

[deleolajide]

Update doap with support for XEP:0483 - HTTP Online Meetings via olmeet plugin

conversejs can now:

auto-discover what audio/video conferencing service is available and configured in XMPP server
request for a web app URL and use it to
invite others to the meeting. If their client supports XEP-0483, the web app can be opened in the chatbox otherwise, it will be opened in the desktop web browser.
fallback on a static base URL configured in config if their XMPP server does not yet support xep-0483.

[Neustradamus]

@deleolajide: Good job!

[linkmauve]

Your use of tabs seems to denote with the rest of the file.

[jcbrand]

Should the DOAP file mention support provided by 3rd party plugins? I'm not sure that it should.

I've been wondering about moving your plugin into the core repo, but I haven't had time to study the XEP and your implementation.

[deleolajide]

Should the DOAP file mention support provided by 3rd party plugins? I'm not sure that it should.

You can blame @guusdk for the suggestion. At Ignite, Openfire plugins (1st party, 2nd party and 3rd party) that implement XEPs are documented in the DOAP.

[guusdk]

I think there's something to be said for both approaches. If a plugin provides a certain feature for your project, that is of interest to people that are scanning for that feature. The notation that clearly signals that this feature is part of a plugin (rather than the core project) in my book is "enough" - but I can appreciate the opposite perspective. In the end, I think DOAP facilitates people looking for usable software for their use case. By listing capabilities, even if they're conditional, you help them.

[jcbrand]

I agree one could make an argument for either approach.

My main concern at the moment is that I don't have control (and don't take any responsibility) over 3rd party plugins and it's easy for these plugins to become unmaintained or forwards incompatible.

To the extent that this plugin could be moved to core, this debate is in any case moot (since no-one has ever proposed updating DOAP for any other plugin).

So, I would like to encourage @deleolajide to make a PR to move this plugin to this repo.

Then we can remove the note from this PR and merge this one as well.

It would mean more work than just copying the code over since I would expect the new plugin to conform to our conventions.

For example:

• utility functions go into plugin/meetings/utils.js
• parsing functions (e.g. parseStanza) go into plugin/meetings/parsers.js
• Add JSDoc with TypeScript annotations

And so forth.

[deleolajide]

So, I would like to encourage @deleolajide to make a PR to move this plugin to this repo.

That's a good solution, but I am unavailable to perform this task at the moment.

[jcbrand]

Too bad. Then I'll close this PR in the meantime.