Presenting the ordered methods needed to retrieve an ordered list of elements from a server

[sammysmallman]

Is there a way to present the steps of a dialogue to retrieve an ordered list of elements from a server and has there been any conversation as to a standard way of doing that.

For instance ETC's Eos Family Consoles (https://www.etcconnect.com/Products/Consoles/Eos-Family/) implements the following methods to retrieve cue information from their consoles:

Step 1:
Client requests how many of an item there is:
/eos/get/cue/<cue list number>/count

Step 2:
Eos will return with the cue count with:
/eos/out/get/cue/<cue list number>/count = <uint32: count>

Step 3:
Client requests detailed information for each item from index 0 to count as follows:
/eos/get/cue/<cue list number>/index/<index number>

Step 4:
Eos returns the detailed information for the item requested.
/eos/out/get/cue/<cue list number>/<cue number>/<cue part number>/list/<list index>/<list count> = <uint32: list index> <string: UID> ...

In this example there are 4 different methods that should be sent in the correct order with the last two being repeated with the index increasing from 0 to count. I wonder how this could be shown in OSCQuery?

[bltzr]

Hi Sam ! Thanks for raising the issue!

If I understand well your concern, I don't think this was ever really discussed here.
I mentioned this at the very beginning of the discussions but nobody replied, so I thought that wasn't so important to others, or that it could be inferred from the order of items in the JSONs (which is actually not the case).

In Jamoma and libossia we're managing this with an extra PRIORITY attribute, that allows us to sort things whenever that's necessary, but that's not part of the specs here (and I'm not sure it should be).

Does that help ?

[sammysmallman]

I think priority helps.. I was looking for some way to query the relationship between the methods and their values, to almost be able to automate retrieving elements from a database for a Table UI Widget possibly.

To use the eos example above:
I would like to know that /eos/get/cue/<cue list number>/count is the first step in the process and that its returned value should be used for step 3 in a loop /eos/get/cue/<cue list number>/index/\<index 0 to index cue count>

In both Jamoma and libossia do you request all elements and then use the priority for sorting? How do you keep elements from client and server in sync with regards to Update, Moving and Deletion?

[mrRay]

"Is there a way to present the steps of a dialogue to retrieve an ordered list of elements from a server and has there been any conversation as to a standard way of doing that."

the data you're requesting (OSC methods in an OSC address space) is structured, but inherently unordered. generally speaking, clients are encouraged to perform whatever sorting they think is appropriate- as pascal just pointed out, applications and users may differ widely in opinion as to the best order for a given set of methods. technically, the order doesn't matter to the OSC spec, and alphabetical listings are common in UIs.

"In this example there are 4 different methods that should be sent in the correct order with the last two being repeated with the index increasing from 0 to count. I wonder how this could be shown in OSCQuery?"

• client requests information about an OSC method (in this case, you might want more information about "/eos/cues", but requesting information about the root method ("/") during startup is also common). the request is a simple HTTP GET to "http://ip:port/eos/cues".

• OSCQuery server returns structured data (JSON blob) describing the OSC method and all of its child methods, which may look something like this (i don't know what your OSC address space actually looks like so i'm making that bit up):

{
	"FULL_PATH": "/eos/cues",
	"CONTENTS": {
		"1": {
			"FULL_PATH": "/eos/cues/1",
			"TYPE": "f",
			<more attribs can be filled in here- VALUE, RANGE, etc>
		},
		"2": {
			"FULL_PATH": "eos/cues/2",
			"TYPE": "f",
			<more attribs can be filled in here- VALUE, RANGE, etc>
		},
		(etc.- these probably won't be in the order "1,2,etc" because this is a JSON object/a key-value store: its contents are inherently unordered)
	}
}

• client parses this structured data using the proposal, which defines a common set of base attributes, and then decides what it wants to do with this information. this is where you'd do any sorting/etc for your interface.

• if the client and server both support websockets, the proposal also offers the ability to send/receive notifications that the server's address space has changed (add/remove/rename), as well as stream values from the server back to connected clients (listen/ignore).

...if you prefer a more methodical approach, it's also possible to work your way through the methods one level at a time, requesting explicit attributes and enumerating the child nodes, but i don't know how common that is or if it's something you're interested in (it doesn't seem faster or more efficient or preferable in any way, but technically, it's possible).

the big difference between OSCQuery and the Eos hardware devices is that the former uses an HTTP server to deliver information about OSC alongside OSC, while the latter has built a custom protocol on top of OSC and as such is a lot more verbose.

"I think priority helps.. I was looking for some way to query the relationship between the methods and their values, to almost be able to automate retrieving elements from a database for a Table UI Widget possibly."

yes, this proposal can be used to programmatically populate table/outline views with UI items. there are already several apps that do this, but the simplest/smallest is probably the browser in this repos:

https://github.com/Vidvox/VVOSCQueryProtocol

"To use the eos example above:
I would like to know that /eos/get/cue//count is the first step in the process and that its returned value should be used for step 3 in a loop /eos/get/cue//index/<index 0 to index cue count>"

i'm not exactly sure what you're asking here, but if it helps i don't think this question would exist at all with OSCQuery, because this protocol would give you a JSON object that fully describes everything in "/eos/cues". if you have that object then you know how many OSC methods there are in /eos/cues, you've already retrieved all the information about them, and you're ready to start sorting/displaying UI items and using them to send OSC messages to the described methods.