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

[Michael Dickens]

> > 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.

Coding, yes, by all/any means a good thing to do by now.

All I'm asking for is a single "For Example" sentence, to justify to 
the reader how an m-block can have 0 external ports.  Every time I've 
read it, I stop and think and wonder; I'm sure I'm not alone.

> > 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.

There is no argument.  I don't disagree that zero cost options should 
be implemented.  Maybe it's too deep of a practical implementation 
issue for now - but wondering if there will be costs to keeping 
everything internal versus making everything separate external blocks 
... or, maybe, if it's just a semantics, to say something to that 
effect, or emphasize what's already been said regarding the nature of 
the m-scheduler and the "m-graph" virtual make-up.

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

Yes, true ... frequently the best documentation is that which is 
written in hind-sight, not fore-sight. - MLD