OHM Orb::Connect::Web 3.19

[Hielor]

Because that way the server doesn't need to keep track of which IDs are free and reusable and which IDs are available.

It's not much of a workaround on the client end to just associate the new ID when you make the new subscription request.

 

[StefanE]

It's not much of a workaround on the client end to just associate the new ID when you make the new subscription request.

Agreed, i was just wondering

 

[Hielor]

It was primarily a desire to keep the server side of things simple, coupled with the architecture of the client I was building at the time (RemoteMFD). It would've also been more work on the client side to remember the old IDs (since each time you switch MFDs it unsubscribes from all the old messages and subscribes to a whole new set), so it just didn't make sense to try to keep track of discarded subscription IDs. It's easier and faster on both ends to just use a new ID.

Is there a specific reason that you want the subscription ID to be re-used after an unsubscribe/resubscribe?

 

[kamaz]

My approach to writing Orb::Connect clients is to have a separate connection for each subscription. It greatly simplifies everything on the client side.

 

[Hielor]

My approach to writing Orb::Connect clients is to have a separate connection for each subscription. It greatly simplifies everything on the client side.

But also defeats the purpose of the subscription ID. It's easy enough for a client to just look at the incoming subscription ID and then route it appropriately. Probably easier to do that than to handle a bunch of different connections...

 

[kamaz]

But also defeats the purpose of the subscription ID. It's easy enough for a client to just look at the incoming subscription ID and then route it appropriately. Probably easier to do that than to handle a bunch of different connections...

Not really is you handle each value in a different thread In which case, parsing the server message is made easier by ignoring everything left of "=".

Yes, I know this is not a way you guys expected the Orb::Connect to be used

 

[StefanE]

Is there a specific reason that you want the subscription ID to be re-used after an unsubscribe/resubscribe?

Depends on the task of the client. If you are in need of variable datasets as with changing MFDs that's ok. If you have a fixed dataset as in a telemetry application it requires a work-around, especially during client development, where you are often disconnecting/reconnecting during debugging.

But as i said, a workaround is no problem.

 

[Hielor]

Depends on the task of the client. If you are in need of variable datasets as with changing MFDs that's ok. If you have a fixed dataset as in a telemetry application it requires a work-around, especially during client development, where you are often disconnecting/reconnecting during debugging.

But as i said, a workaround is no problem.

I hope you're not trying to hardcode the subscription IDs. That would be Bad.

Even with a fixed dataset you should be using the returned subscription ID, so it shouldn't be a problem during client development/debugging.

Remember, it's always possible that someone else is connecting to the same Orb::Connect server and making subscriptions before you do, so it's never a valid assumption that "first subscription from my app equals 1000".

Unless of course the IDs are per connection...but I don't remember the code well enough to know that anymore...