[Tinyos-devel] Re: [Tinyos Core WG] Proposal for VariableSizedQueueC component

[Philip Levis]

On Sep 18, 2007, at 10:05 PM, Kevin Klues wrote:

>> How about calling it QueueP.nc? Also, would this also make sense with
>> PoolP?
>
> The problem is that we also need to redefine the Queue interface to
> contain a new parameter, not just tack it onto a new QueueP component.
>
> We need Queue to look like this now:
> interface Queue<t, queue_size_t> {
>   command queue_size_t size();
>   command queue_size_t maxSize();
>   command t element(queue_size_t idx);
>   ....
> }
>
> So the question is whether we want to leave QueueC backwards
> compatible with the way it was or not.

I think breaking QueueC is a bad idea; this is the first time its  
limited size has come up. Another, perhaps simpler approach might be  
to just have a BigQueue interface, which is the same but with a  
uint16_t. I mean, there really are only 4 possibilities for the  
parameter -- uint8_t, uint16_t, uint32_t, and uint64_t -- and the  
largest two seem very unlikely. The only reason to go through the  
level of indirection that a typed component introduces is code reuse;  
I certainly hear enough grumbles about the levels of indirection, and  
this one might be a wash. I personally kind of liked that QueueC was  
so simple; John Regehr recently proved it correct.

Phil