unknown
1970-01-01 00:00:00 UTC
<br>
Your use of OSC communication might differ substantially from this, and I g=
uess the question of e.g. a server-based versus peer-to-peer communication =
topology will radically change how OSC queries will have to be done. Maybe =
it would be an idea to develop a number of scenarios or sue cases that coul=
d help illuminate the different needs.<br>
</blockquote><div><br></div><div>My situation is reverse: currently no cont=
rol changes that happen internally are broadcasted (connections are just fu=
nction calls). This is fast but not very nice for external devices. I think=
there is no best architecture and this is why I it makes sense to use the =
same distinction data/control for internal communications. Sometimes we nee=
d fast (but non-followable) signals and sometimes we want to pay the broadc=
asting overhead because we need external devices to follow the changes.</di=
v>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
<br>
Finally, concerning the propositions, the distinctions you now suggest woul=
d help. Based on your suggestion, and what we currently do in Jamoma, I wou=
ld like to suggest modifying it to e.g:<br>
<br>
1. get state =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/get<br>
<br>
The /get addition for (1) would be a huge improvement to us as compared to =
/some/url. This also ensures that if a get state request is sent to a oscit=
-non-complient system, the address won't fit the internal namespace, an=
d hence hopefully be ignored or throw an error message<br>
<br>
2. set state =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url<br>
<br>
This is the most common task, and also the one that has been around for lon=
g. Any non-oscit-complient application =A0is likely to support this, so we =
ensure backwards compatibility.<br></blockquote><div><br></div><div>This me=
ans all changes on "/some/url" are broadcasted (control), right ?=
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">
<br>
3. subscribe =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/subscribe<br>
<br>
This one makes a lot of sense to me.<br>
<br></blockquote><div>This is only for data sources, right ? Registration f=
or control changes is done for the whole device with "/osc/register&qu=
ot;.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
4. data sink =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/<br>
<br>
For the data sink I can imagine either using the same command as for set st=
ate, or use a fourth candidate, e.g. /some/url/updated=A0</blockquote><div>=
<br></div><div>As I said above, I think we need explicit distinction betwee=
n signal targets that are "data sinks" from "control changes=
" because this is where the notification will take place or not.</div>
<div><br></div><div>I liked the "/set" postfix for control change=
s (with notification) and the raw url for data sink (without notification).=
I think this way compatibility is even better: old applications can receiv=
e messages but will typically not notify, hence the default to "data s=
ink".</div>
<div><br></div><div>On an implementation perspective the "/set" p=
ostfix is interesting because the "controller" who will also be i=
n charge of notifications can easily detect the "control" message=
s, strip the "/set" postfix, call "/some/url", call &qu=
ot;/some/url/get" and notify. This means that objects just need two me=
thods "/some/url" (data sink) and "/some/url/get" (get =
current state) in order to act both as control and data. Not implementing &=
quot;/get" means that the resource is a data sink only (impulse for ex=
ample).</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
In Jamoma we use the same as for get state. Developers will have to ensure =
to avoid a feedback loop if it is broadcasted and picked up again by the sa=
me application, but the resulting namespace that can be accessed and used f=
or mappings e.g. using the OSC-map application, will be a tidy one.<br>
<br>
BTW: Have you looked into CooperLan? I know Pascal Baltazar was really impr=
essed with their design decisions, wo it might be worth studying.<br><br></=
blockquote><div>I looked at CooperLan but could not find the protocol descr=
iption on their website... Moreover, since their protocol is probably well =
protected by all kinds of copyrights and patents and ugly monsters, I am no=
t sure I want to put my head in the dragon...</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Gaspard=A0</div></div>=
<br>
--005045013ed02602ed048e41e46e--
Your use of OSC communication might differ substantially from this, and I g=
uess the question of e.g. a server-based versus peer-to-peer communication =
topology will radically change how OSC queries will have to be done. Maybe =
it would be an idea to develop a number of scenarios or sue cases that coul=
d help illuminate the different needs.<br>
</blockquote><div><br></div><div>My situation is reverse: currently no cont=
rol changes that happen internally are broadcasted (connections are just fu=
nction calls). This is fast but not very nice for external devices. I think=
there is no best architecture and this is why I it makes sense to use the =
same distinction data/control for internal communications. Sometimes we nee=
d fast (but non-followable) signals and sometimes we want to pay the broadc=
asting overhead because we need external devices to follow the changes.</di=
v>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
<br>
Finally, concerning the propositions, the distinctions you now suggest woul=
d help. Based on your suggestion, and what we currently do in Jamoma, I wou=
ld like to suggest modifying it to e.g:<br>
<br>
1. get state =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/get<br>
<br>
The /get addition for (1) would be a huge improvement to us as compared to =
/some/url. This also ensures that if a get state request is sent to a oscit=
-non-complient system, the address won't fit the internal namespace, an=
d hence hopefully be ignored or throw an error message<br>
<br>
2. set state =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url<br>
<br>
This is the most common task, and also the one that has been around for lon=
g. Any non-oscit-complient application =A0is likely to support this, so we =
ensure backwards compatibility.<br></blockquote><div><br></div><div>This me=
ans all changes on "/some/url" are broadcasted (control), right ?=
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">
<br>
3. subscribe =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/subscribe<br>
<br>
This one makes a lot of sense to me.<br>
<br></blockquote><div>This is only for data sources, right ? Registration f=
or control changes is done for the whole device with "/osc/register&qu=
ot;.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
4. data sink =A0 =A0 =A0 =A0 =A0 =A0=3D> /some/url/<br>
<br>
For the data sink I can imagine either using the same command as for set st=
ate, or use a fourth candidate, e.g. /some/url/updated=A0</blockquote><div>=
<br></div><div>As I said above, I think we need explicit distinction betwee=
n signal targets that are "data sinks" from "control changes=
" because this is where the notification will take place or not.</div>
<div><br></div><div>I liked the "/set" postfix for control change=
s (with notification) and the raw url for data sink (without notification).=
I think this way compatibility is even better: old applications can receiv=
e messages but will typically not notify, hence the default to "data s=
ink".</div>
<div><br></div><div>On an implementation perspective the "/set" p=
ostfix is interesting because the "controller" who will also be i=
n charge of notifications can easily detect the "control" message=
s, strip the "/set" postfix, call "/some/url", call &qu=
ot;/some/url/get" and notify. This means that objects just need two me=
thods "/some/url" (data sink) and "/some/url/get" (get =
current state) in order to act both as control and data. Not implementing &=
quot;/get" means that the resource is a data sink only (impulse for ex=
ample).</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
In Jamoma we use the same as for get state. Developers will have to ensure =
to avoid a feedback loop if it is broadcasted and picked up again by the sa=
me application, but the resulting namespace that can be accessed and used f=
or mappings e.g. using the OSC-map application, will be a tidy one.<br>
<br>
BTW: Have you looked into CooperLan? I know Pascal Baltazar was really impr=
essed with their design decisions, wo it might be worth studying.<br><br></=
blockquote><div>I looked at CooperLan but could not find the protocol descr=
iption on their website... Moreover, since their protocol is probably well =
protected by all kinds of copyrights and patents and ugly monsters, I am no=
t sure I want to put my head in the dragon...</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Gaspard=A0</div></div>=
<br>
--005045013ed02602ed048e41e46e--