-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Minuit] i-score send minuit requests for attributes that does not exists #80
Comments
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. |
i-score requests for rangeBounds and rangeClipmode when it receives Data. |
I understand that's usefull for i-score, but we just need to make a clear documentation of the minuit implementation of i-score. |
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...) |
From what I've read about minuit, these parameters are just need for i-score implementation… 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. |
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. 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 ? |
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.
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. We just need to documentate a minuit implementation chart in the iscore documentation that just says the following : Implementation of the Minuit protocol :
|
aka How to expose my software to i-score over the minuit protocol. |
I really think that 'rangeClipmode' and 'rangeBounds' should be changed in Jamoma - this is just a matter of @theod setting his time towards this |
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...). |
I totally agree |
"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 |
I'm adding @jcelerier as an observer, to make sure this makes it to i-score 0.3 |
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. |
This is another example of Minuit being way too entangled with Jamoma !!! |
Create a minuit device that have a container without attributes
i-score sends 'get' requests about priority, service and tags.
The text was updated successfully, but these errors were encountered: