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

Implicitly assumes service_path = '/' #199

Open
Kleinjohann opened this issue Aug 26, 2024 · 2 comments
Open

Implicitly assumes service_path = '/' #199

Kleinjohann opened this issue Aug 26, 2024 · 2 comments
Labels
on hold Not prioritised

Comments

@Kleinjohann
Copy link

All entities created in entirety have service_path='/', and entities with with service_path!='/' are not shown in the entities tab. Is this intentional / am I missing a setting for this somewhere?

@djs0109
Copy link
Collaborator

djs0109 commented Aug 26, 2024

Hi @Kleinjohann that is good notice! Yes, it is our intention not to use/support service_path. Previous experience showed that service_path brings more problems than value.

@SBlechmann
Copy link
Contributor

We have had this discussion for several years and we decided to go with the support of just "/" as servicepath for the moment.

Orion offers the possibility to use wildcards in servicepaths in get queries, so that all servicepaths can be queried with "/#". I believe I have already opend an internal discussion 2 weeks ago with the core developers because orion supports this.

Nevertheless, iota and orion's subscription endpoint (in contrast to the documentation!) do not support wildcards yet, check this issue which will bring inconsistencies.
While we can still discuss whether reading entities from all servicepaths is a good solution, the servicepath itself is not part of the response. This way you do not know in which servicepath the entity originates when querying /#.
Thus, you can't use this information to query the iota for device information or the subscription endpoint.

Maybe this clears some things up why entirety currently only supports "/" for now.

@djs0109 djs0109 added the on hold Not prioritised label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold Not prioritised
Projects
None yet
Development

No branches or pull requests

3 participants