Antwort: Re: Re: Re: Contained Sequences

Dave;

Like many other communications systems applications, our internal data
structure is reasonably complex, and the "table-within-a-table" problem
would actually need to be "supported" at many different levels.

We are essentially running a proprietary radio network (hence
low-bandwidth) with each network being comprised from a number of
"stations". Egress data is queued, per-station, on a per-priority basis and
ingress data is processed via a seperate set of queues, again, one for each
station (from which data can be received).

Furthermore, within a single application instance a multiple number of
radios (and hence networks) is to be supported. I hope you can begin to see
the problem...

One App, many networks, many stations, many queues..... Essentially then, a
table within a table within a table within a table....

Oh dear.

On top of all of this, we have had to modify/"personalise" a number of the
scripts that were provided to comply with our architecture, not also to
mention the fact that this particular development is subject to some rather
strict quality standards (RTCA and DOA do not completely, but almost,
apply).

I will have a look at the example you cited to see if there is anything in
that which can be used.

Martin




"Dave Shield"
<D.T.Shield@csc.l
iv.ac.uk> An
Gesendet von: "Martin.Cooke@rsd.rohde-schwarz.co
dave.shield@googl m"
email.com <Martin.Cooke@rsd.rohde-schwarz.co
m>
Kopie
25.07.2006 17:54 net-snmp-users@lists.sourceforge.n
et
Thema
Re: Re: Re: Contained Sequences










On 25/07/06, Martin.Cooke@rsd.rohde-schwarz.com wrote:
> No need to get tetchy, I was only asking...

I wasn't getting tetchy - I was only telling :-)


> No offence intended, but my experience with academia has not always been
> equitable. A good number of academic types have responded with "won't"
> rather than "can't".

Ah,but I'm not an academic - I'm a techie.
I just have to *work* with academic types.....

> I need to figure out which one applies here.

Please see:
http://www.pantherfilm.com/faq2.html#2_37_01

(which is part of an FAQ that's been effectively untouched for several
years. This is not a new requirement).


> Between this "problem" and other problems, I am beginning to wonder if
> selecting CMIP/CMISE would not have been preferrable...

No comment.

There's actually no difficulty in implementing this sort of pair of
linked tables. Presumably there is some underlying data structure
that represents whatever information you are trying to report on? As
long as that's kept up to date, you can implement the two tables
independently. The fact that they're both working with a shared data
source means that the table-within-a-table aspect falls out
automatically.

Merging things back together again for display at the client end is a
slightly different problem. But there's nothing inherently difficult
about this - it's just a simple matter of programming.

I can't comment about the other problems you refer to, for obvious reasons.

Dave



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?p...rge&CID=DEVDEV
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users