On Tue, Apr 8, 2008 at 9:29 AM, Dimas Abreu Dutra <[EMAIL PROTECTED]> wrote:
> Great! The message.getSerialPacket() solves the problem of getting the
> source and even other issues like getting the group the message sender
> belongs to. An interface redesign will, with no doubt, cause older programs
> to stop working, so I believe that the current solution offers the best
> compromise.
Sounds reasonable. Also, my feeling was that MoteIF/Message need a
fairly deep spring-cleaning (the set of methods, constructors, etc is
rather weird/arbitrary). I won't have time to do it, though :-(
David
>
> ~Dimas~
>
>
>
> On 4/6/08, David Moss <[EMAIL PROTECTED]> wrote:
> > This isn't the first time we have discussed this issue. Although I think
> > the interface is not ideal as it exists right now, a patch has already
> been
> > implemented that allows a developer to access the source address without
> the
> > need to change the interface and break existing code.
> >
> > All packet information, including everything in the packet's header, is
> > available in the SerialPacket that the Message was created from. The fix
> > that was implemented months ago allows you to access the original
> > SerialPacket from the Message you received. From the SerialPacket, you can
> > access that source address and any other header information you want.
> i.e...
> >
> > public void messageReceived(int to, Message message) {
> > int source = message.getSerialPacket().get_header_src();
> > //...
> > }
> >
> > If an interface change is in store, maybe the solution is to provide a
> > Message and its original SerialPacket so you can access whatever you want,
> > and not limit things to just the source or destination address. A
> > completely and painful redesign might allow all the information to be
> > accessed directly through the Message.
> >
> > public void messageReceived(Message message, SerialPacket packet) {
> > int source = packet.get_header_src();
> > }
> >
> > You can get at anything you want to as the code exists now, and that is
> > probably be a better solution than changing the interface and causing code
> > management problems throughout the community. A new major revision of
> > TinyOS will be able to get away with safely fixing that interface, if
> > there's consensus to do so.
> >
> > -moss
> >
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
