[Minuit] i-score send minuit requests for attributes that does not exists

[reno-]

Create a minuit device that have a container without attributes i-score sends 'get' requests about priority, service and tags.

[theod]

not sure to understand how do you create a container without attribute … do you mean using the xml file ? or do you mean in Max you create a model without @priority, @tag, … ? or adding a node via the + button ?

[reno-]

I'm writing a minuit plugin in modul8, so I'm following the minuit implementation guide (readme file of the minuit repo)

From what I understand, minuit will make a get request about the attributes it receives from a node. But in the i-score implementation, it will ask for priority, tag, and service attributes even if these are not provided in the namespace request.

[reno-]

i-score requests for rangeBounds and rangeClipmode when it receives Data.

[reno-]

I understand that's usefull for i-score, but we just need to make a clear documentation of the minuit implementation of i-score.

[bltzr]

It's just that these attributes names deviated from the Minuit specs to accomodate to Jamoma names (which BTW could be brought back to the names chosen in Minuit, now that we've simplified the attribute names in Jamoma4Max.... anyway...) This is clearly one of the reasons why I think that Minuit isn't Minuit anymore, and that it's way too much entangled with the Jamoma implementation... To be further discussed...

[reno-]

From what I've read about minuit, these parameters are just need for i-score implementation… Minuit protocol is designed to have containers and data that have attributes.

JamomaProtocol is a Minuit Protocol with mandatory attributes

i-score have an implementation of Minuit with a few mandatory attributes : 'priority' 'service' and 'tags' for container and 'priority' 'service', 'tags', 'value', 'rangeBounds' and 'rangeClipmode' for Data.

I understand that at some point JamomaProtocol could diverge from Minuit… but that's another story.

[bltzr]

These parameters are needed to implement views or other bindings across Jamoma applications on the network (and i-score is one of them).

'rangeBounds' and 'rangeClipmode' are diverging names from the Minuit specs, and they should be fixed in one place or the other (preferably in Jamoma IMHO -> to 'range' and 'clipmode')

I think that considering JamomaProtocol as a flavor of Minuit Protocol is a sane perspective. Fact is that, being the only really implemented flavor, it kind of contaminated Minuit's spec - but this can still be fixed in Jamoma I also know that Jamoma uses other node Types than Data or Container (e.g. Model, Preset, or Data.in... etc..), but I don't know if that's 1. well specified in the Minuit specs 2. a problem for remote Minuit implementations discussing with Jamoma over Minuit I also think that the attributes you mention (service, tags, priority) should be added (as optional) to the Minuit specs (if they are not already there...)

Yes, JamomaProtocol could diverge from Minuit in the future, that's a possibility (even if not a desirable one), but for now, the fact is rather that Jamoma pushed Minuit to diverge from itself...

Yet another question (my initial one in the jBoD) was to decide whether Minuit should be renamed to JamomaProtocol (or rather Query, as it is less a protocol than a query system). This question is maybe becoming obsolete if developers implement again Minuit in their applications (as you're doing in Modul8)

Sinon, c'est mignon de se parler en anglais... non ?

[reno-]

range and clipmode sounds better, for sure.

Anyway, I like to consider that Jamoma implemented the minuit protocol and I agree that's sane to keep Jamoma and i-score 'Minuit Compliant'. It might be done from one part or another, I don't really care as long as we documentate it.

I also know that Jamoma uses other node Types than Data or Container (e.g. Model, Preset, or Data.in... etc..), but I don't know if that's 1. well specified in the Minuit specs 2. a problem for remote Minuit implementations discussing with Jamoma over Minuit Model, Preset and Date are 'services' of a 'Data' or a 'Container'. From what I can see, that's perfectly fits the readme of minuit github

The power of Minuit is that it is just a way to transport. It's really free inside. And that will be nice to narrowed a bit things, as introduce parameters, models but it can be done in minuit 0.3

But for now, i-score asks for special attributes to organise the tree view. It uses value attribute of a data when it make an event … etc…

The original issue is that i-score request for 5 attributes even if these are not provided by the previous minuit reply describing Container or Data. And of course it use the :value attributes for events.

We just need to documentate a minuit implementation chart in the iscore documentation that just says the following :

---

Implementation of the Minuit protocol :

• Container must provide 'tags', 'service' and 'priority' attributes
• Service of a Container must be model
• Data must provide following attributes : 'priority', 'service', 'tags', 'rangeClipmode', 'value', 'rangeBounds'
• Service of a Data must be 'parameter', 'message' or 'return'.
• i-score will interact with parameters and messages for making events and with returns and messages for conditional events.

[reno-]

aka How to expose my software to i-score over the minuit protocol.

[bltzr]

I really think that 'rangeClipmode' and 'rangeBounds' should be changed in Jamoma - this is just a matter of @theod setting his time towards this

[bltzr]

BTW all of this (adding parameters, models, etc...) is really pulling Minuit towards Jamoma... I'm not sure if that is desirable if we really want to keep Minuit as open as possible... IMHO, all of these optional attributes should remain optional and i-score (i.e. its JamomaModular Minuit plugin) should be able to deal with their absence (e.g. no service for a Data means parameter...).

[reno-]

I totally agree

[bltzr]

"Service of a Container must be model": it doesn't have to - a Container can just be a Container, without any model... AFAIR, requests for model services are an ad-hoc solution (aka workaround) here to avoid displaying views in i-score's device explorer in i-score 0.3 this should (and will !) be managed in a more generic way

[bltzr]

I'm adding @jcelerier as an observer, to make sure this makes it to i-score 0.3

[theod]

actually in Minuit Protocol there is a redundancy because Data mean an object with a known set of attribute so it should not be needed to send the attribute description as all Data object have the same set of attribute. It is partly a design problem of Minuit or of 0.6 tree architecture as we would like attribute to be considered as one more node level in 0.7 … not sure what I can do from i-score point of view because it can't decide if it have to send request or not considering the information it have.

[bltzr]

This is another example of Minuit being way too entangled with Jamoma !!! Because if we wanted to keep Minuit Jamoma-independent, then this set of attributes wouldn't have to be mandatory, or required to function with anything...