[PD-dev] namespaces for send/receive

[Hans-Christoph Steiner]

On Nov 16, 2009, at 9:18 PM, Luke Iannini wrote:

> 2009/11/16  <zmoelnig at iem.at>:
>> Quoting "Hans-Christoph Steiner" <hans at at.or.at>:
>>
>>>
>>> I am in the process of working on my 'framesync' library, and I  
>>> just  had
>>> a thought that I am not sure has come up before.  Lots of times,   
>>> we want to
>>> use send/receives in reusable code, but with a global  namespace,  
>>> there is
>>> the potential for nameclashes.  So I propose that  for libraries,  
>>> we make it
>>> a 'best practice' to use the same namespace  prefix as you would  
>>> for loading
>>> an object.
>>>
>>> For example, this 'framesync' library, I need to send the FPS  
>>> (Frames  Per
>>> Second) to all the objects, so it needs to be a global send.  So   
>>> just like
>>> I could do [framesync/fstabplay~]  the internal send/receive   
>>> would be [send
>>> framesync/fps] and [receive framesync/fps].
>>
>> while you are there, i would propose to use "/foo/bar" rather than
>> "foo/bar".
>>
>> while this doesn't fully match the [foo/bar] idiom for object- 
>> names, it does
>> fit nicely into OSC.
>
> (okay, time-warping self-nullifying emailing at its best - see ending
> parenthetical for my most up-to-date thinking on this matter.  I think
> I agree with IO after all).
>
> Just a quick comment... when I was writing and pondering the (still
> very small) Pd Style Guide I decided it wasn't a good idea to use "/"
> in send/receive namespaces.
>
> The reason being, I didn't see a point in making s/r addresses look
> like OSC addresses if they /weren't/ always OSC addresses, and that it
> would be better to be explicit about how OSC fits into the picture in
> cases where it actually does.
>
> I used "-", like [s framesync-fps] (which matched well with what
> miller and the majority of Pd users do habitually anyway (albeit with
> no discernible formality in most cases).
>
> Anyway, it's not meant as an attempt to bikeshed, just wanted to  
> mention it : ).
>
> (Ah, and just as I was about to hit send, I think I finally get the
> idea of doing this: it's so one could receive incoming OSC messages
> like [/framesync/fps 5( and then use a dynamic [send] to dispatch them
> to the right [recieve]s!  I was stuck thinking you'd need a bunch of
> [routeOSC]s everywhere which, in my previous experience, slowed my
> patches to a crawl.).


Having the send/receive name the same as an OSC name sounds like a  
great idea if you are using OSC.  But Pd != OSC, and I'd guess most Pd  
users never use OSC.  I think we should follow Debian's lead here and  
use the same name everywhere.  The remarkable consistency of Debian is  
a key reason why its so nice to use it.  So in Debian, we have a  
package called 'foo', then you have:

foo-1.0-1_i386.deb
/usr/share/foo
/usr/share/doc/foo
/usr/share/applications/foo.desktop
/etc/foo
/etc/init.d/foo start
/etc/default/foo
/usr/lib/foo
/var/lib/foo
/var/log/foo

The only changes to the name 'foo' are when they are required, like  
'.desktop' and '-1.0-1_i386.deb'.  Since we are talking about Pd here,  
we can use one naming convention is as many places as possible.  Then  
those who want to use OSC to send to these standardized symbols can  
use an object that strips off the leading slash, if need be.

.hc



----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own  
government." - Martin Luther King, Jr.