DCCL messages not compiling.

Hi -

The pre-release versions of DCCL used "(goby.msg).dccl" and "(goby.field).dccl" option extensions. In the final release (for a variety of reasons), this was changed to "(dccl.msg)" and "(dccl.field)" respectively. Please see the examples at http://gobysoft.org/doc/2.0/acomms_dccl.html

Sorry for the confusion.
-t

Thank you for the explanation.

Looking back I see that the release notes indicate DCCL had been refactored, but I don't see an indication that all existing Protobuf messages in a project would need to be reconfigured as a result. Aside from the changelog, was there some place I should have looked for a listing of such changes that would require reconfiguration?

In general, I am concerned about the functionality of project materials that were compiled/written based on pre-release versions of DCCL. For example, skimming the updated DCCL how-to, I see that there is now a DCCL ID assignment table. I may be wrong but I do not remember this table existing when our Protobuf message files were written last summer. The existence of the table suggests that certain ID's are now reserved and imply a certain message type. Will Protobuf messages using these reserved ID numbers behave differently than they did before? If not, under what circumstances should one take the ID assignment table into consideration?

Thank's again for your responses and explanations,
-Jake

The changelog is the place to look, but you should expect not to see a breaking change like that in any future 2.0 release. Please remember that you were using a pre-release version, and I apologize for the trouble this has caused you.

The DCCL ID table (http://gobysoft.org/wiki/DcclIdTable) serves roughly the same purpose as the IANA port assignments (http://www.ietf.org/assignments/service-names-port-numbers/service-names-port-numbers.txt). The goal is to allow different institutions / companies to inter-operate by assigning fixed DCCL IDs.

In other words, if Institution A chooses id 22 for one message, and institution B chooses id 22 for a different message, they cannot interoperate in a collaborative experiment without one institution changing the ID number.

As far as DCCL is concerned, the ID number doesn't matter as long as they are consistent throughout the whole network (every ID uniquely defines a given protobuf Message). If you control all your nodes, you can assign the IDs as you wish. However, I strongly recommend using the "Private / Testing" IDs or requesting a block of assigned IDs. This way you won't run into trouble if you end up doing a collaborative experiment down the road.

Also note that encoded DCCL messages from 2.0.1~rc1 and newer is binary compatible with the 2.0.2 decoder (and vice versa), it's simply the option extension names that have changed.