OSCQuery: Support for optional attributes?

[joreg]

i'm particularly interested in PATH_ADDED and PATH_REMOVED attributes for Server->Client communication as defined here: https://github.com/Vidvox/OSCQueryProposal#server---client-communication-attributes

i am sending those from my oscquery server implementation but they don't seem to have an effect. are those supposed to work?

here is what i send:

{"COMMAND":"PATH_ADDED","DATA":"/foo/bars"}
{"COMMAND":"PATH_REMOVED","DATA":"/foo/bars"}

apart from those, can you provide a list of which the optional stuff is supported in chataigne?

[joreg]

also can you explain what Sync does?

[benkuper]

Sync allows to not create the inner container data. When you are syncing a big structure without thousands of parameters, it's really nice to not have a giant structure to load and manage from the software. So it's mainly for optimization and convenience.

As for the supported options, I implemented a basic implementation to work with most existing software, and most of them don't implement those functions. But I actually recently implemented them as server in organic apps, so it would make sense to implement them in the OSCQuery module.

I'll add that to the roadmap. You can definitely keep it there and it should just work at some point with Chataigne :) Right now, you would just have to hit the "Sync Data" button.

[joreg]

one more: when i click the listen button (on above screenshot) i receive 2 LISTEN commands:

• /foo/bars
• /foo/sync

is the "/foo/sync" one on purpose? if so, what is it meant for?

[benkuper]

Yes, right now the LISTEN on Chataigne side is on the Container level, meaning that you can't choose to listen only one parameter in a container. It was mainly for ease of development and UI, and considering that most of the time it won't be a problem. There is no actual limitation on the fact that it could be on a parameter level

[joreg]

but why send "/foo/sync"? since this is not a parameter on my server the only thing i can do with it is ignore it. but what would then be its usecase?

[benkuper]

aaah sorry. yes it's a bug :)