Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Sitemaps #594

Closed
davidgraeff opened this issue Feb 22, 2019 · 9 comments
Closed

Question: Sitemaps #594

davidgraeff opened this issue Feb 22, 2019 · 9 comments

Comments

@davidgraeff
Copy link
Member

I have a few questions. Let me first list the following facts:

  • Sitemaps is a concept to interact with OH (read: external API via tcp/http).
  • HaBots cards is a concept to interact with OH (read: external API via tcp/http).
  • Hue emulation is a concept to interact with OH (read: external API via tcp/http).

And now my questions that arise building up on those facts:

  • Is sitemaps (or a successor) the only allowed concept in core?
  • Can sitemaps be moved to openhab2-addons: addons/io like all the other interactions?
  • Can habots cards be added to core? (Useful for the new unified UI as well as native apps!)
    • If so: Should habots cards be moved to core or better to openhab2-addons: addons/io?
  • Does it make sense to have an own repo for "addons/io"?

Cheers, David

@flaviocosta-net
Copy link

Hi @davidgraeff, Sitemaps and HaBots indeed are some sort of User Interface - while Hue emulation is not a UI per se, it acts as a technical bridge for external voice UIs.

I have read on another issue your comment that sitemaps are limited, so last year I have started working on a sitemap re-implementation that would address most limitations and current user requests for sitemap features. With the changes needed due to the termination of the Eclipse SmartHome project and due to the lack of spare time, I have halted the development with about 60% of the code ready, but I am now considering resuming this work.

Given the information I have collected while working on that, here are my comments on your questions:

I don't think sitemaps must be in the core. While it is perhaps the most used UI option, it is not necessarily more "central" than other ways of interacting with the system, and we can imagine many use cases for OH without any sitemaps at all.

The sitemap implementation I am working is actually quite a bit of work, with many new bundles, so I would actually appreciate it being moved somewhere else. However, it is not true that other interactions are in openhab2-addons: addons/io. Sitemaps are in openhab-core, HaBots are in openhab-webui, only Hue emulation (which is not a UI per se, as I've mentioned above) is under openhab2-addons.

If we want to follow your idea and improve the separation between the core and the various UIs, perhaps we could do the following:

  • Keep Hue emulation under openhab2-addons
  • Put the new sitemap implementation under openhab-webui, and maybe rename this project to openhab-ui since I don't see sitemaps as being necessarily a JavaScript/UI module.
  • Leave the existing sitemap implementation under core, deprecate it once the new implementation is ready, so it can be removed in a future release.

What do you think? It would be great to have the community feedback on this, to resume the work on the new sitemaps in a clean new location.

@davidgraeff
Copy link
Member Author

davidgraeff commented Nov 4, 2019

I'd say -webui should be cleared off from any java code and be purely javascript/css/html. It's like the -android or -ios repositories. They also do not have own OH-core addon code, they rely on OH core to provide an interface.

If sitemaps are moved, they should probably end up in openhab2-addons or a new "openhab2-io" repo. Addons that provide an external interface are "io" addons in OH, not "ui". I would say that should actually happen anyway, because at the moment sitemap code can be found all other the place, that's what I have noticed when I tried to modernize the rest interface.

@ HaBot: I have extracted the HaBot chat interface and added a PR to include it into core. That PR is not moving forwards though.

Anyway, a sitemap replacement io interface is possible to be submitted to openhab2-addons as any other io addon before. And the Android and IOs maintainers need to be convinced of the new interface, but that's not that hard I guess. Sitemaps is not the best http interface or let's say it has aged.

I'm not using OH anymore though except for addon maintenance, so can only speak for myself here.

@flaviocosta-net
Copy link

Add-ons under openhab2-addons are typically implemented by 1 project/bundle each, but the new sitemap implementation was more like 10 bundles... it does not fit so well in the openhab2-addons project structure. If the currently recommended approach would be to have that on a new openhab2-io project, that sounds fine to me, but a clear and confirmed definition is needed so packages can be moved accordingly.

Obviously, if you implement a custom web UI with JavaScript/AJAX/REST, you have endless options on what you can do, but this path is not for everyone. Sitemaps are for a different audience, for people that is not knowledgeable enough to build a custom solution or just don't want to spend time on that. The original proposal to revamp the sitemap implementation was to address many aspects that made it an aged solution (limited customization, cannot be updated via a REST API, not extensible, etc.)

Well, sounds like I can move forward with renaming packages as org.openhab.io.sitemap.* and start adjusting/finalizing the code, as the decision to move it to a separate/new project could happen later.

@kaikreuzer
Copy link
Member

@flaviocosta-net Nice to see you here again - I was under the impression that you had given up the work that you did.

I do not agree that sitemaps should be moved to any other place than core. They are meant to be the central way of declaring UI content with those declarations being shared among different UIs.

When we discussed the new sitemap concept, HABot wasn't around at that time. I think before going into many implementation details, we should discuss the way forward with @ysc as well as with the native app maintainers, so that there is a buy-in from everyone who will has to adopt the new concept.

Could you maybe open a WIP PR here on openhab-core (or merely an issue, if the current version of your code is hard to get in here), summarizing the major parts of the concept from eclipse-archived/smarthome#5337?

@flaviocosta-net
Copy link

flaviocosta-net commented Nov 6, 2019

Hello @kaikreuzer, I was actually overwhelmed with changes at work, and then the reintegration of the code to OH started happening, I hope now to find a bit more time to resume and complete this work (and deliver the expected benefits such as the possible REST API management of sitemaps).

I will check how complicated it will be to move it to openhab-core structure now. Thanks!

@davidgraeff
Copy link
Member Author

FYI: If you are handling with rest endpoints, you should directly use the OSGI R7 Whiteboard pattern design.

@kaikreuzer
Copy link
Member

Still, I have a question: why are the sitemap bundles under org.openhab.core.model, instead of org.openhab.core.ui? Just trying to better understand those architecture choices.

Although you have deleted this question, let me answer it anyway: The "model" bundles is everything related to Xtext and DSLs. The new bundles should indeed be placed unter org.openhab.core.ui!

@kaikreuzer
Copy link
Member

If you are handling with rest endpoints, you should directly use the OSGI R7 Whiteboard pattern design.

No, it should be in line with all our other REST endpoints. But yes, maybe we are able to change them all at once as suggested in #726 (comment).

@digitaldan
Copy link
Contributor

@flaviocosta-net looking forward to seeing your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants