[Tinyos-devel] Parameterization of UartStream interface in UART abstraction on all platforms?

[Vlado Handziski]

The only problem is that it currently supports SVN only. But maybe it is
time to make that jump also :)

Vlado

On Thu, May 22, 2008 at 8:22 PM, Vlado Handziski <handzisk at tkn.tu-berlin.de>
wrote:

> As I said during the teleconference, I think that it is time to migrate to
> a proper issue tracker, independent from SF. Neither e-mail, nor wikis alone
> are particularly suitable for tracking tickets and reviewing patches. If we
> want something lightweight, I think Rietveld from GvR fits the bill quite
> nicely:
>
> http://code.google.com/appengine/articles/rietveld.html
>
> TUB is also ready to host such a tracker, the only problem would be the
> domain, since most of the tinyos are taken. But maybe the holders will be
> happy to release them back to the community.
>
> Vlado
>
>
> On Thu, May 22, 2008 at 8:10 PM, Kevin Klues <klueska at gmail.com> wrote:
>
>> Glancing through the code one last time, both SpiPacket and I2CPacekt
>> aren't parameterized on the atmega128 either.   Whenever the changes
>> for UartStream get made, they will need to be made for these guys too.
>>
>> We need to start maintaining a TODO list of things that need to get
>> done and cross them off one by one as they happen.  There's the file
>> 'overall-todo' in the tinyos-2.x root, but its extremely outdated.
>> I'm going to create a page on the TinyOS wiki to this effect and
>> hopefully people will start using it.....
>>
>> I'm also going to remove the current 'overall-todo' file and replace
>> it with a TODO.html that redirects to the wiki if there are no
>> objections.
>>
>> Kevin
>>
>> On Thu, May 22, 2008 at 1:51 AM, Vlado Handziski
>> <handzisk at tkn.tu-berlin.de> wrote:
>> > On Thu, May 22, 2008 at 9:43 AM, Philip Levis <pal at cs.stanford.edu>
>> wrote:
>> >>
>> >> On May 21, 2008, at 6:34 PM, Kevin Klues wrote:
>> >> > I'm inclined to say we should just leave well enough alone until a
>> >> > specific need for it arises.  I normally hate to say this, as I'm all
>> >> > for consistency across platforms when appropriate, but in this case
>> >> > there are reasons not to do so such as (unnecessary) code bloat and
>> >> > incompatibility with legacy code that we dont know about (i.e. not in
>> >> > the standard tree).  If someone is willing to put in the effort
>> >> > required to make this change I say go for it.  I've just got too many
>> >> > other things going on to make all the necessary changes and do them
>> >> > well, given that there is not a pressing need for them at the moment.
>> >>
>> >> This makes sense to me. We should defer doing it until we need to.
>> >> Otherwise we have to maintain unnecessary complexity.
>> >>
>> >
>> > I agree with postponing this after the release, but I don't think we
>> should
>> > wait concrete request pops-up. All HALs should by default be ready to be
>> > arbitrated. It is not a large change, and if the overhead is a problem
>> we
>> > can always start with NoArbiterC
>> >
>> > Vlado
>> >
>>
>>
>>
>> --
>> ~Kevin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080522/d67da3e8/attachment.htm