search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
91 stars 68 forks source link

Add Apps API page #542

Closed rob42 closed 5 years ago

rob42 commented 5 years ago

Documenting the signalk/v1/apps API

rob42 commented 5 years ago

Freeboard-sk loads your choice of instruments in a sidepanel. It needs to be able to get name, url. I would like to see KIP do the same in reverse, so you create an MFD by inserting apps into panels.

I included search, install, remove so that they could potentially offer options that were not currently installed. Plus self upgrade

sbender9 commented 5 years ago

Got you. Like it! And now I want to do this in WilhelmSK ;)

sbender9 commented 5 years ago

Can we add some kind of “status” to the data from /list? Maybe with values like available, installing, ‘installation failed’?

Maybe installed/restart required in case the server need restarted after installation? Or maybe I just need to fix node server so restarts aren’t required after install :(

rob42 commented 5 years ago

That supposes the install process has a well-defined process and outcome and the wrapper can store data on that somewhere. Outside of node/npm, install is just download the archive, unpack, and search for the index.html (all over the place..). No real way to know if its ok.

I create the list output by traversing the install dirs and parsing package.json. So if its there its listed. I create the search list by a search and then mark the installed ones, which allows me to add a 'Remove' button. But thats server specific really, adding extra data to the reply json

rob42 commented 5 years ago

given the mess of current webapps package formats I think that needs sorting first

panaaj commented 5 years ago

Some added value to consider (not mandatory though) is meta-data that can allow inclusion of app icons, etc to be displayed when listing apps... for example #629

rob42 commented 5 years ago

Added the manifest.json if it exists "manifest": {..content of manifest.json..}

Adding manifest.json instead of icon etc has the side effect of encouraging std deployments.

sbender9 commented 5 years ago

@rob42 I don’t see the issue with status. Node server provides this already. Maybe make it optional in case the server can’t provide it?

rob42 commented 5 years ago

Theres no problem sending additional data thats implementation dependent. Its especially useful for a servers app management ui. When the install is just unzip, if its there status=INSTALLED, there is no FAILED state, just a failed install, eg there is no way to tell its installed but not working. So I dont see how it would be useful.

rob42 commented 5 years ago

Maybe installed/restart Since a webapp is just a bunch of static files a reboot seems a bit extreme 😮 Maybe needed for plugin installs though. Out of scope for now

sbender9 commented 5 years ago

Lots of things could fail when installing one of these. No internet. Missing dependencies. No disk space.

I think letting the user know that the install failed would be very useful. And like we do with node server, actually show the user information as to why it failed would be great too.

I think providing a way for users to install web apps and not giving them any way to see the progress and results of the install is short sighted.

rob42 commented 5 years ago

I think you misunderstand me. Definitely things can fail in the install, and showing progress is useful, but I see that as part of the install process, which is implementation dependant. This api is just to find installed apps, search for apps, and being able to request an install or remove is just a conveinience

How would you structure feedback from the install?

rob42 commented 5 years ago

@sbender9 ?

fabdrol commented 5 years ago

Would it be out of scope to add to this that a server may provide the apps via the various HTML5 discovery protocols of the MFDs (i.e. Garmin OneHelm & Navico's implementation)?

rob42 commented 5 years ago

Would it be out of scope to add to this that a server may provide the apps via the various HTML5 discovery protocols of the MFDs (i.e. Garmin OneHelm & Navico's implementation)?

I think that falls under implementation. The implementation is free to do whatever, this is about signalk webapps.

fabdrol commented 5 years ago

I think that falls under implementation

@rob42 I agree that the how falls under implementation, but way could promote this ourselves. This is an area where Signal K could really come to its own...

tkurki commented 5 years ago

I agree with Rob.

I don't quite see how saying that a server may support manufacturers' propietary system X (where each manufacturer has their own prop way of doing things) is useful, even if X is something that Signal K does / could do well.

A server may support all kinds of things, the spec should concentrate on Signal K.

fabdrol commented 5 years ago

Okay, in that case shall we merge?

rob42 commented 5 years ago

Yes