Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking"

[Eric Blossom]

On Thu, Jun 15, 2006 at 08:13:52AM -0400, Michael Dickens wrote:
> On Jun 15, 2006, at 2:03 AM, Eric Blossom wrote:
> >On Thu, Jun 15, 2006 at 12:51:05AM -0400, David Lapsley wrote:
> >>On 6/14/06 2:24 PM, "Michael Dickens" <address@hidden> wrote:
> >>
> >
> >>>p68, 4.8.1; and p74, 4.8.4: How can an m-block have zero ports?  I
> >>>thought that all data / metadata / signals / whatever were
> >>>transported via these ports.  Without a port of any type, what  
> >>>can an
> >>>m-block do?
> >>
> >>Not much!  This is a bug.  I'll fix it.
> >
> >Actually an m-block could have zero external ports with no problem.
> >In fact that's exactly what the top level m-block looks like ;)
> 
> OK, I'll bite.  How does data get into or out of something with zero  
> external ports?  Via internal ports?  So, e.g., a source could be  
> made internal-only, and connect internally to other m-blocks, and  
> eventually drop to an internal-only sink?

Yes.  Or it may not have anything to do with "signal processing".  It
could all exist in the one m-block.  The initial transition will
be triggered.  It's free to request timeout notifications from the
system (which sends a message to an internal port).  It could just go
about it's business without talking to any other block.  Yes, I know
this isn't all documented, but I think it's time to start coding. 

> Are there any advantages to setting up this way versus using a
> single m-block per signal- processing concept (source, processing,
> sink)?  IMHO it would be helpful to have a quick example in the
> text, just to be (more) complete. - MLD

I'm not going to spend the time arguing the point.  However, it
would be short sighted to preclude something that could be useful and
has zero cost to implement.

The real documentation for this stuff will be written after it's coded ;)

Eric