Third Argument to Peer in Examples.scd

[sidechained]

Hi all,

Just in the process of testing out these classes, and noticed what appears to be an error in two places in the Examples.scd, as follows:

Line 32:

Peer(\me2, NetAddr.localAddr, s.addr)

Line 63:

Peer(\me2, NetAddr.localAddr, s.addr)

For both these lines, isn't the third argument to Peer supposed to be the online status of the peer? Is there a reason for the server address here at all?

Regards, Graham

[muellmusik]

Hey Graham,

That's from an older version where Peer held a server object, but I managed to make that unnecessary.

So just delete s.addr from those examples. Sorry, thought I'd caught them all.

S.

On 29 Apr 2013, at 18:55, sidechained notifications@github.com wrote:

Hi all,

Just in the process of testing out these classes, and noticed what appears to be an error in two places in the Examples.scd, as follows:

Line 32:

Peer(\me2, NetAddr.localAddr, s.addr)

Line 63:

Peer(\me2, NetAddr.localAddr, s.addr)

For both these lines, isn't the third argument to Peer supposed to be the online status of the peer? Is there a reason for the server address here at all?

Regards, Graham

— Reply to this email directly or view it on GitHub.

[sidechained]

Hey Scott,

Okay cool, thanks - I'd taken them out anyway. Makes sense that they used to be there for a reason. From what we were talking about in Karlsruhe, I guess the plan now is that server objects should be placed in an OSCObjectSpace?

Cheers, Graham

On Mon, Apr 29, 2013 at 6:58 PM, muellmusik notifications@github.comwrote:

Hey Graham,

That's from an older version where Peer held a server object, but I managed to make that unnecessary.

So just delete s.addr from those examples. Sorry, thought I'd caught them all.

S.

On 29 Apr 2013, at 18:55, sidechained notifications@github.com wrote:

Hi all,

Just in the process of testing out these classes, and noticed what appears to be an error in two places in the Examples.scd, as follows:

Line 32:

Peer(\me2, NetAddr.localAddr, s.addr)

Line 63:

Peer(\me2, NetAddr.localAddr, s.addr)

For both these lines, isn't the third argument to Peer supposed to be the online status of the peer? Is there a reason for the server address here at all?

Regards, Graham

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/muellmusik/NetMusicLib/issues/1#issuecomment-17182978 .

[muellmusik]

On 29 Apr 2013, at 19:03, sidechained wrote:

Hey Scott,

Okay cool, thanks - I'd taken them out anyway. Makes sense that they used to be there for a reason.

Yeah, just an earlier stage of the design where I hadn't thought it through enough and I was trying different approaches for server sharing.

From what we were talking about in Karlsruhe, I guess the plan now is that server objects should be placed in an OSCObjectSpace?

Yes, although you would probably exchange instances of NetAddr, as you don't really want to copy a Server and all its state. You could also use different strategies for that, for example sending ip addresses and ports as integers in OSCDataSpace and then generating NetAddrs from them. That would be more secure. We could make a dedicated class to do that if desired.

Anyway, at this stage I'm not sure of the optimal approach, but the main thing was to move the server addr out of Peer. Having it there makes a simple class a little less simple and a little more heavy, and more importantly carries with it certain assumptions (e.g. a Peer has only one server) which I felt it best to avoid. I've been trying hard to assume as little as possible about what people will want to do and how, and to keep it open enough to straightforwardly enable multiple ways of working.

S.

[muellmusik]

I fixed the example file, so I'm closing this...