Krishna Sankar wrote:
D) Unless we are leveraging the bus for other functionalities, avahi
*might* be slightly heavyweight; we might have to implement
ZeroConf on the bare metal
Not sure why this is.
<KS>
Couple of points : One of my concern was the DBUS (may be not a valid
concern, especially if we are leveraging the DBUS in OLPC). Second,
because of the various constraints, the ZeroConf might have to be aware
of the underlying mesh substrate. For example your thought of 'use mDNS
for 2 hops' is a good optimization, but what if one really needs to
publish to a network that has higher diameter ? May be ZeroConf does a
re-publish. I am postulating. As Jim pointed out in one of the e-mails,
the NS2 simulations would not help us here; we really need to
"experience" the mesh substrate through the apps that ride the Zeroconf.
May be a collaborative piano app would need > 2 hops. One thing is
certain - we need a few good knobs and counters, so that we can tune the
substrates to fit the layer 7 apps, naturally under the covers.
Yeah, we're using dbus. dbus + zeroconf + avahi makes it _incredibly_
easy to write an app. But, yeah, testing is key. We'll have to start
testing it out pretty soon.
--Chris
--
olpc-software mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/olpc-software
