Skip to content
This repository has been archived by the owner on Sep 21, 2021. It is now read-only.

@managedport decorator for sm #50

Open
roblabla opened this issue Apr 6, 2019 · 3 comments
Open

@managedport decorator for sm #50

roblabla opened this issue Apr 6, 2019 · 3 comments

Comments

@roblabla
Copy link
Member

roblabla commented Apr 6, 2019

SwIPC currently defines that IUserInterface is sm:. However, this is not technically correct: to connect to sm:, we have to connect to the kernel-managed port "sm:", and not the sm-managed port. In fact, the kernel suports having multiple such managed ports (up to 7 of them).

I propose we add a @managedport decorator to service definitions, so it turns into IUserInterface is @managedport sm:. It's kinda ugly, so any prettier proposal would be appreciated.

@misson20000
Copy link
Member

Perhaps turn it into an annotation that applies to the interface definition? Maybe we should do that for sm registrations, too and just drop the is syntax. Would give a good way to represent registration changes on different versions.

@roblabla
Copy link
Member Author

roblabla commented Apr 6, 2019

Could you elaborate? You mean having something like this?

@managedport(sm:)
interface Whatever {
}

That would work. Though for versioning, we'd need to have something like a @cfg_attr(version, decorator)

@misson20000
Copy link
Member

I mean

@managedport(sm:)
interface Whatever {
  ...
}

yeah, and then for regular registrations something like:

@registration(appletAE)
interface nn::am::service::IAllSystemAppletProxiesService {
  ...
}

@registration(ns:am2, ns:ec, ns:rid, ns:rt, ns:web)
interface nn::ns::detail::IServiceGetterInterface {
  ...
}

Now that I think about it, I don't know if a service has ever changed registration, but we could notate it like:

@registration([1.0.0-3.0.0] oldname, [3.0.1+] newname)
interface ChangesRegistration {
  ...
}

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

No branches or pull requests

2 participants