Feature Request #740

jcom.send/receive addresses with no leading slash should be relative

Added by Théo de la Hogue over 6 years ago. Updated almost 6 years ago.

Status:ClosedStart date:2011-03-14
Priority:LowDue date:
Assignee:Théo de la Hogue% Done:

0%

Category:-Spent time:-
Target version:MVC for 0.6
Branch:

Description

[jcom.send /absolute/address] is looking from the root of the namespace
while [jcom.send relative/address] should look from the model/view node.

History

#1 Updated by Théo de la Hogue about 6 years ago

Just copying an email Tim sent to explain the POSIX format :

" Hopefully I can help to clarify the slash situation, or at least the history behind it.

The slash is not part of the name. If it is a module, a parameter, a return, a container, etc. The names are the things between the slashes. The slashes separate the names.

So a parameter is not named "/bitdepth" it is named "bitdepth". In OSC it may be set using
/degrade/bitdepth 8
in JSON it might set using as {
"degrade": {
"bitdepth" : 8
}
}
There are no slashes in the JSON version.

Back to jcom.send -- this is an object using OSC to address a node in the tree. OSC uses slashes in style similar to POSIX directories (the stuff you see in the Mac Terminal.app for navigating the files and folders).

In the filesystem you specify a node (a file or a folder) from the root of the tree by beginning the address with a slash. You specify a node (a file or a folder) relative to your current location by not using a slash.

So if you are in a module with [jcom.send my/param/without/leading/slash] I would presume that you are addressing my/param/without/leading/slash as something deep within the bowels of this particular module. If there were a slash at the beginning it would be using the global namespace because the leading slash means to start at the root.

Have I managed to make sense? Or have managed to just make everyone more confused? I hope I am managing to help!

best,
Tim "

#2 Updated by Théo de la Hogue about 6 years ago

Another Tim's advice about POSIX format for remote devices :

" When we begin thinking about remote devices, I think it might be a good idea to again use the POSIX filesystem as a reference. Specifically, we can look at the way ssh and scp work. If I want to access a file or folder on the remote file system I use this syntax:

scp    /some/local/file    username@some_remote_device:/the/path/to/the/remote/file

If I already have some ssh magic stuff setup, then I don't need to use my username and just do this:

scp    /some/local/file    some_remote_device:/the/path/to/the/remote/file

The colon could be confusing in Jamoma because we've used it to mean something else, but maybe we can be smart about it somehow and figure out what it means from the context?

best,
Tim "

#3 Updated by Théo de la Hogue about 6 years ago

Considering thoses hints I would part way back from the leading slash for other externals.

For jcom.send/receive : we seems agree...

For parameter|message|return declaration :
with a leading slash a warning would appears only when we are editing the module : "you are registering /foo from the root. Remove the leading slash to make the subscription relative to your model" or something like that...

For jcom.view : if we consider the jcom.view as a jcom.send/receive it should follow the same convention

For jcom.hub : we should ban leading slash (with an error message in Max window)

For jcom.namespace : with no leading slash, starts the exploration from where it is in the hierarchy

For jcom.map : what do you think ? It could provide some powerfull routing features...

For jcom.init : what do you think ? It could provide some powerfull routing features...

and about address with remote device part (localhost@appDistant:/my/distant/parameter)
this make only sense for : jcom.send, jcom.receive, jcom.view, jcom.map, jcom.namespace and jcom.init

Anything to add ?

#4 Updated by Théo de la Hogue about 6 years ago

  • Status changed from New to Resolved

#5 Updated by Pascal Baltazar almost 6 years ago

I was about to close the issue when I remembered something I came across this afternoon :

I tried to create a [jcom.send someAdress] in a view patcher, when the desired addressed was a parameter of the model and not of a view... and then I realized that this relative address was not referring to the model, but to the view

this seems to make perfect sense, but at the same time, my first reflex was to do as described above... and it took me some time to figure out that I was wrong...

anyone having an idea about this ? (maybe also this requires some practice of 0.6 to have an opinion...)

#6 Updated by Pascal Baltazar almost 6 years ago

  • Status changed from Resolved to Assigned
  • Priority changed from Normal to Low

Concerning the remote application/device address formatting :
the mechanism is already implemented in this way
remoteApp:/my/nice/local/path:property
which an argument for not changing it...
but maybe not a good enough argument, if there are other concerns...

as Tim wrote :
The colon could be confusing in Jamoma because we've used it to mean something else, but maybe we can be smart about it somehow and figure out what it means from the context?
That's what Théo did : he's been very smart (he usually is :-) - but then the computer has to be smart also when checking every address (and there can be a lot of them in the timespan of a second ...) :
instead of checking just one character at the beginning of the string ( is it @,/ or anything else ?), it has to check if two contiguous characters ( :/ ) are present anywhere in the string - my C++ skills are not very impressive, but I guess this makes a big difference, performance-wise...

Apart from that, I'm not sure we have to stick to POSIX so firmly because :
2/ we already made an exception for attributes, with the colon
1/ the usage is not completely the same, as this discussion show it :
Théo :
it seems that @ used to be the username in POSIX system.
Julien :
Just to make sure, when sending messages locally, we do not need to add the "localhost:" part, right ?
and this implies some potential misunderstandings....

so, to conclude, my impression is that we should stick to the KISS solution which would be :
@remoteApp/my/nice/local/path:property
which is simple to read and parse both for me and my computer...

#7 Updated by Pascal Baltazar almost 6 years ago

  • Status changed from Assigned to Closed

the feature request indicated in the title is now implemented
the POSIX discussion below has been copied to a new issue : http://redmine.jamoma.org/issues/802

Also available in: Atom PDF