Change Details

Andy Holmes @nicofee since I see you're on plugins right now, has it ever been discussed making *Capabilities in the identity packet dynamic? Nico Fe You mean announcing new capabilities after pairing? Andy Holmes more like 'activeCapabilites', as in I can currently handle these packets If i recall kdeconnectd has a DBus property/method loadedPlugins, but that's for local I believe Nico Fe So you would like to be able to get the capability infromation from the identity package on request? Andy Holmes yeah, as an indication what plugins the remote device has enabled there's an obvious hurdle to using that disable enabling plugins the other device hasnt enabled, but could give an indication "/!\ The remote device hasn't enabled this plugin" just curious if that was ever proposed Nico Fe AFAIK not, but I've only been around for a year or so Let me check whether caps are re-announced when plugins get en/disabled Okay, obviously that is not the case. What about sending an Identity package (or something containing the caps) when the enabled plugins change? Or is there a reason for plugins to have dynamic caps? Andy Holmes probably not plugin (only exception I know of being sms), but it could be useful to know what plugins/capabilities a remote device has enabled currently you can only tell what packets a device could *possibly* handle, not what it actually will if you send one Nico Fe Ah, I see. I assumed that only the caps of the enabled plugins are announced, but I just saw that this isn't the case. So, how does only announcing the caps of enabled plugins in the identity package and re-announcing them when the enabled plugins change sound? Andy Holmes Well, the only problem with that is it would prevent another client from loading the plugin, since it would think it just doesn't support it. So if it were phone<->phone neither could enable a plugin the other hadn't already enabled, which neither could :) Nico Fe On the other hand, it would be useful to know which plugins the other device theoretically can handle though\ Andy Holmes Yeah, I think it would have to be seperate field Nico Fe So, add a list of enabled caps to the identity package and re-send when changed? Andy Holmes something like incomingEnabled, outgoingEnabled what do you think, though? Useful? Nico Fe I guess Andy Holmes heh, well maybe I'll bring it up on the mailinglist so everyone sees it and the idea gets some more feedback/use-cases

From the Telegram group: Andy Holmes: @nicolasfella since I see you're on plugins right now, has it ever been discussed making *Capabilities in the identity packet dynamic? Nico Fe: You mean announcing new capabilities after pairing? Andy Holmes: more like 'activeCapabilites', as in I can currently handle these packets If i recall kdeconnectd has a DBus property/method loadedPlugins, but that's for local I believe Nico Fe: So you would like to be able to get the capability infromation from the identity package on request? Andy Holmes: yeah, as an indication what plugins the remote device has enabled there's an obvious hurdle to using that disable enabling plugins the other device hasnt enabled, but could give an indication "/!\ The remote device hasn't enabled this plugin" just curious if that was ever proposed Nico Fe: AFAIK not, but I've only been around for a year or so Let me check whether caps are re-announced when plugins get en/disabled Okay, obviously that is not the case. What about sending an Identity package (or something containing the caps) when the enabled plugins change? Or is there a reason for plugins to have dynamic caps? Andy Holmes: probably not plugin (only exception I know of being sms), but it could be useful to know what plugins/capabilities a remote device has enabled currently you can only tell what packets a device could *possibly* handle, not what it actually will if you send one Nico Fe: Ah, I see. I assumed that only the caps of the enabled plugins are announced, but I just saw that this isn't the case. So, how does only announcing the caps of enabled plugins in the identity package and re-announcing them when the enabled plugins change sound? Andy Holmes: Well, the only problem with that is it would prevent another client from loading the plugin, since it would think it just doesn't support it. So if it were phone<->phone neither could enable a plugin the other hadn't already enabled, which neither could :) Nico Fe: On the other hand, it would be useful to know which plugins the other device theoretically can handle though Andy Holmes: Yeah, I think it would have to be seperate field Nico Fe: So, add a list of enabled caps to the identity package and re-send when changed? Andy Holmes: something like incomingEnabled, outgoingEnabled what do you think, though? Useful? Nico Fe: I guess Andy Holmes: heh, well maybe I'll bring it up on the mailinglist so everyone sees it and the idea gets some more feedback/use-cases

From the Telegram group: Andy Holmes: @nicofeelasfella since I see you're on plugins right now, has it ever been discussed making *Capabilities in the identity packet dynamic? Nico Fe: You mean announcing new capabilities after pairing? Andy Holmes: more like 'activeCapabilites', as in I can currently handle these packets If i recall kdeconnectd has a DBus property/method loadedPlugins, but that's for local I believe Nico Fe: So you would like to be able to get the capability infromation from the identity package on request? Andy Holmes: yeah, as an indication what plugins the remote device has enabled there's an obvious hurdle to using that disable enabling plugins the other device hasnt enabled, but could give an indication "/!\ The remote device hasn't enabled this plugin" just curious if that was ever proposed Nico Fe: AFAIK not, but I've only been around for a year or so Let me check whether caps are re-announced when plugins get en/disabled Okay, obviously that is not the case. What about sending an Identity package (or something containing the caps) when the enabled plugins change? Or is there a reason for plugins to have dynamic caps? Andy Holmes: probably not plugin (only exception I know of being sms), but it could be useful to know what plugins/capabilities a remote device has enabled currently you can only tell what packets a device could *possibly* handle, not what it actually will if you send one Nico Fe: Ah, I see. I assumed that only the caps of the enabled plugins are announced, but I just saw that this isn't the case. So, how does only announcing the caps of enabled plugins in the identity package and re-announcing them when the enabled plugins change sound? Andy Holmes: Well, the only problem with that is it would prevent another client from loading the plugin, since it would think it just doesn't support it. So if it were phone<->phone neither could enable a plugin the other hadn't already enabled, which neither could :) Nico Fe: On the other hand, it would be useful to know which plugins the other device theoretically can handle though\ Andy Holmes: Yeah, I think it would have to be seperate field Nico Fe: So, add a list of enabled caps to the identity package and re-send when changed? Andy Holmes: something like incomingEnabled, outgoingEnabled what do you think, though? Useful? Nico Fe: I guess Andy Holmes: heh, well maybe I'll bring it up on the mailinglist so everyone sees it and the idea gets some more feedback/use-cases