Subject: Re: [netmod] augment target

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 08:19:07 -0500

Balazs Lengyel writes:
>IMHO this is not such a rare case. Our designers have been asking for it alrea
>dy.
>We can live with the current solution, but it's not nice.

The current scheme is that your can use submodules, but if you do,
you should use them completely, putting nothing in your main module
that any submodule might (ever) need.  In a way, it's an all or
nothing approach.  This simple approach avoids many corner issues.
I don't see any convincing downside or "not nice" issues.  If you
want submodules, use them thoroughly.  If you don't, avoid them.

Thanks,
 Phil
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 14:58:41 +0100

> nothing approach.  This simple approach avoids many corner issues.

Like what? IMO the only change would be that the symbol lookup will
continue from the submodule to its parent module's top level context. I
am not aware of any problem this could cause.

> want submodules, use them thoroughly.  If you don't, avoid them.

The downside is of course that if you have definitions that are common
to the main module and submodules, you can't use them from the main
module but rather they have to be put to a special submodule. This means
that adding a submodule may sometimes require refactoring the main
module or copying the needed definitions under different names to the
submodule.

Also, if I remember correctly from the interim, Balazs demanded that the
"top-level augment" continue to be able to address target nodes in the
local module, not just in external modules, and the use case was the
possibility of attaching submodule content to a non-root node in the
main module. So this actually is not allowed, right?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 09:28:32 -0500

Ladislav Lhotka writes:
>Like what?

One of the use cases for submodules is to allow separate compilation.
If submodules include modules which include submodules, this is no
longer reasonable.

>module but rather they have to be put to a special submodule.

This isn't a downside, but a requirement that you put definitions
that are common into a submodule, so that can be used by other
submodules.  This gives us a BCP of "don't put anything in the
module except the include statements for submodules and any glue
needed to tie them together".  If you use submodules, you should
use them completely, avoiding putting anything in the module that
submodules might need.  Can you give a use case where this isn't
possible?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 17:04:03 +0100

> If submodules include modules which include submodules, this is no

How this could be a problem given that namespaces of different modules
are completely separated? I don't know what this "separate compilation"
exactly means, but there cannot be any conflict between unresolved
references to the parent module and external module (whether it has
submodules or not).

> submodules might need.  Can you give a use case where this isn't

The decision to use submodules may come in a later phase. I am not
saying something is impossible, just that it is clumsy and not for a
good reason. The best place for common definitions is the parent of all
submodules.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Dec 2008 09:44:43 -0800

> Phil Shafer píše v Po 01. 12. 2008 v 08:19 -0500:
....
> main module. So this actually is not allowed, right?

Really?
In that case there is no point to the CLR that augment-stmt only appear
at the top-level or insides uses-stmt.  The only use-case was the when
clause, but that is now allowed everywhere, not just inside augment-stmt.

Unless the top-level augment is 'external namespace only',
then augment-stmt should be allowed everywhere.  Nothing whatsoever
is simplified in the code but removing only one of the two
local augment variants.  It just gives users one more CLR
to remember and work around.

>>  Phil

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 21:36:40 +0100 (CET)

> > main module. So this actually is not allowed, right?

Well, the idea was that a sbumodule can still augment (top-level) a
node which is defined in another submodule:

  submodule S1 {
    container routing { ... }
  }

  submodule S2 {
    include S1;
    augment /routing {
      container ospf { ... }
    }
  }

> local augment variants.

I agree that the code might not be simplified, but I'm not sure we
should allow augment anywhere anyway.

> It just gives users one more CLR

'augment' can be used on the top-level only.
'extend' (or whatever it will be called) can be used in 'uses' only

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 21:51:36 +0100

>     container routing { ... }

The draft says: "When a submodule includes another submodule, the target
submodule's definitions are made available to the current submodule."
This example seems to imply that not only definitions but also data
nodes (routing) are made available.

> should allow augment anywhere anyway.

My preference is to have the top-level augment only for external
targets.

> 'extend' (or whatever it will be called) can be used in 'uses' only

'append'?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 21:56:33 +0100 (CET)

> nodes (routing) are made available.

We need to define the term "definition"...  The definition of the node
is available (i.e. the name 'routing' is available as a container).

This does *not* mean that the definition is duplicated.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Dec 2008 13:03:09 -0800

>     container routing { ... }

So there is going to be a CLR that this is only allowed in submodules,
when augmenting other submodules?  Seems rather arcane to me.

I don't really care.  I already went to the trouble of
making every aspect of YANG validation 'stmt order proof',
so magical augment nodes that drop in from who-knows-where are not a problem.

I guess this counts as a use-case, so I drop my objection.
Just document it well because this is confusing.

> 'extend' (or whatever it will be called) can be used in 'uses' only

Well, what is it called?
If it can only appear in uses, then a different name
than augment is a good idea.  IMO, 'extend' is fine.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 22:06:05 +0100 (CET)

> than augment is a good idea.  IMO, 'extend' is fine.

One worry is that it might be confused with 'extension'.  But if
people don't think that will be a problem, then I think 'extend' is
fine.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 22:10:45 +0100

> is available (i.e. the name 'routing' is available as a container).

Oh, since the "include" statement is explained separately for modules
and submodules, I thought "definition" in the latter case meant either
definition of a grouping or typedef. Perhaps it is better to talk about
inclusion of symbols.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 16:09:42 -0500

>This does *not* mean that the definition is duplicated.

Nor that it is transitive.  If s1 includes s2 which includes s3,
typedefs in s3 are not available to s1.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 22:27:50 +0100

> typedefs in s3 are not available to s1.

Why bother then with forbidding circular includes? Without transitivity,
no loops in symbol lookup can build up.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 16:39:18 -0500

>no loops in symbol lookup can build up.

Sure they can.  S1 includes S2 which includes S3 which
includes S1.  Each submodules defines a grouping that
uses a grouping from the included submodule.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 16:42:00 -0500

Ladislav Lhotka writes:
>I don't know what this "separate compilation"
>exactly means...

This refers to allowing the toolset to compile each module or
submodule independently.  You needn't compile all submodules at the
same time.  This reduces the footprint of the compile in terms of
memory and cpu.  Unchanged submodules need not be recompiled when
they (and anything they've included) does not change.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 23:06:14 +0100

> uses a grouping from the included submodule.

What you probably mean is just infinite recursion in definitions and you
can make it in a single module, too. It's not a problem of circular
includes.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Dec 2008 14:45:35 -0800

> can make it in a single module, too. It's not a problem of circular

There are several opportunities for the DM writer to
mess up and define some sort of inter-module
or intra-module definition loop.
You should detect all of them.

Your compiler cannot blindly start S1 while compiling S3,
and then off into S2, and then S3, and round and round.
These should be errors because when you get to 'include S1'
inside S3, you better know not to honor it, or you will start a loop.
Since you cannot honor it, it should be an error.

Andy