Walk into packages

[temsa]

Adds a helper to walk into packages, which will be more than useful to retrieve message definitions to avoid message generation.

FYI, on my laptop, here is some performance information :

var packages = require('./lib/packages');

//time to reach one package in my ROS_WORKSPACE
console.time('pack');
packages.findPackage('turtlenode', function() {console.timeEnd('pack')})
//logs "pack: 37ms" 

//time to reach the tutorial stack package 'turtlesim'
console.time('pack');
packages.findPackage('turtlesim', function() {console.timeEnd('pack')})
// logs "pack: 107ms"

Walking algorithm may use parallelization rather than chain, but it will be pretty much more difficult to find which entry has the precedence (and to stop when the good one is retrieve) in the path if multiple package matches, and hard drives are pretty poor at parallel search (... but this is not true for flash or ssd, which may be used in robots), so it can globally slows the search if we have only one package matching the name.

We can also add some cache pretty easily (like rospack does, we can even share the cache with it), but it's not done yet.

Please note that it does not follow symlinks for now.

Please note it's not that well tested against 'rospackage_nosubdirs' file, but it should take it in account

[temsa]

I have implemented locally walking through symlinks, but now search is twice slower... Should we support symlinks ?

[temsa]

ok I'm pushing the symlink walking, as I've resolved the performance problem :)

[baalexander]

Thanks for the pull request! The functionality looks solid. I will take a deeper look over the weekend and plan to merge it into the 0.1.x branch.

[temsa]

I've started to implement message generation and I'm targeting 0.1.x, what format should I use for the generated message classes ? Like now, using backbone, or not ?

[baalexander]

Backbone is going away completely at this level (though there may be something separately that provides a backbone layer on top for the web).

I'm not really sure the best format for a generated message. Something lightweight and works in the browser and Node.js. Maybe straight up JS objects? Or a ros.message constructor for an object?

The key part is the properties the message will have. In addition to the actual message fields, we need field types (bool, uint16) and the order of the fields as defined in the message definition file. This is for serializing and deserializing the messages for TCPROS and UDPROS.

Thanks again for taking a look into this.

[temsa]

I guess there is 2 things we should maybe not melt:

• fields definition and order
• the message itself

My guess is, the message itself should be as simple as possible in order not to disturb the user. It should be a class so it's type can be checked, but it should look as much as possible like a vanilla JavaScript object with just the properties of the messages (it won't be hard to put backbone back on top of such an object either).

So, we should probably :

• have a registry which stores the order of the fields and the field types of the object
• have empty JavaScript object with just a named constructor so we can check there type thanks to "instanceof"
• when we emit a message, validate the messages properties types, emit only defined fields, ignore any extra field, thanks to the definition that is stored in the registry

What do you think of that ?

[baalexander]

I am all for simplifying the message, like a ros.Message constructor for an empty object.

I forgot about validation (something I was taking for granted in Backbone). A validation exception message on the socket could be a good solution, but a possible issue is you publish 100 messages before you receive the validation message.

Since field order and types may only matter for the robot implementation and not the browser, a message registry sounds ideal. I want to confirm with rosbridge folks first (who are collaborating on the web js stuff) that they don't need field order or type being passed into rosbridge.

@trevorjay - Does/can rosbridge accept JSON for a message without all the fields defined (only setting linear.x for a geometry_msgs/Twist for example)? Do you need field order or field types in the JSON being passed in?

[baalexander]

Merged lib/packages.js into 0.1.0-wip branch.