My working notes for the intercast networking project
+ Collate from notes and memory a sketch of the new design.
: see external_fit_and_internal_form.brec
+ Compose the remainder in outline only.
/ Outline only because already the drawings do most of the work.
+ Outline from the salvage tasks of the present file.
: see `^*━━━━━ S a l v a g e`
+ Describe implicitly formed (by way-file tap) goal forest edges.
- With reference (‘e.g.’) to diagram.
+ Ensure the term and form compendia are complete.
: see lexicon.brec
: see network_composition.brec
+ Ensure forms are defined (where appropriate) as particular types of waycast parameter.
: set <role offer> team member *waycast URI*
: set <role acceptance> team member *appointer waycast URI*
: see `^+Waycast parameterizer$` @ ~/code/WP3/wayic/Waybrec/language_definition.brec
+ For compound parameters, form subparameters as children.
: set <role offer> team leader *waycast URI*
: set <portfolio>
: set <role acceptance> team leader *appointer waycast URI*
: set <portfolio> foo.brec `bar/.*`
+ Define each in sections of three types.
: privately see notebook:2021-7-13a
+ Index the project terms.
: see ~/code/WP3/way/index.brec
general fractal taps, viz. other than thoroughfractal head taps
- These await a concrete or otherwise compelling use case.
- Their prospective utility is hampered because they could not easily be used to support
arboreal discovery of the resulting variants.
- Unlike the variants of thoroughfractal heads and file fracta, those of fracta in general
lack any common identifiers on which to form forests.
- These would require weight fractioning.
- Where a waycast contained multiple instances of the waysource represented in the forest
by multiple nodes, its nodal weights would be fractioned to a combined total of one.
/ E.g. dividing each by the node count.
: cf. `^*- Whether or not path bridges transfer descendant weight` @ `^*way-file forest$`
@ network_composition.brec
━━━━━ S a l v a g e ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━
Pipe
──────
+ Standing model differences will not support file renaming.
- For sake of easier implementation.
- File renaming has no compelling use case in the context of a pipe stand, where one repairs
broken references, inserts comments (e.g. integrators), and the like.
─────────────────────
executive resources
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
executive forest
- The role forest of all roles.
/ Viz. regardless of role.
role forests
- Each is a forest of executive relations for a particular role.
- Edges are defined by a combination of pipe and role relations.
- The single out-edge of a node extends to a direct executive superior
and meets one or both of the following conditions.
/ The anti-arborescent form constrains a forest to at most one out-edge per node.
• It is (based on) a pipe extending to any direct superior.
/ Viz. from stand to stock on condition the stock waycaster
appoints the stand waycaster to a role.
• It is (based on) the acceptance of a role offered by
a direct superior who is the sole superior.
/ Viz. it extends to an executive superior who is the only direct superior,
no appointment being accepted from any other.
- A role forest may be reordered based on executive tree.
- This is to aid exploration in forests of high tree count.
- The descendant weights that order the forest are taken from the roots
of the equivalent executive trees.
- How narrower categories of forest might be defined, explored and sought
within a particular role forest.
• Narrowing the role according to file path
/ This would require that (at least some) roles specify a set of file paths.
- This would yield a subset of trees, namely those whose bases appoint
to the narrower role.
/ Especially to find teams.
• Goal or branch of goal forest
/ Especially to find executive trees.
- This would yield a subset of trees, namely those whose basal models
declare a goal that meets the criterion.
━━━━━━━━━━━━━━━━━━━━━
Waysource integrity
─────────────────────
/ Waysource integrity is a function of waysource maintenance and overall executive
integration, which in turn are both parts of way execution.
- The official waysource integrator of a way part is charged with the coherence of
its waysource and (except for the root integrator) cooperating with superiors and
peers to integrate it with that of other way parts.
- A waysource integrator’s appointment offer names the way part (any name will do).
/ Multiple integration offers each for a different way part
may be extended to the same waycaster.
- Any acceptance echoes the name and defines the files of the way part.
: re `defines.+ the way part` see `^*definition of way parts$`
- Appointment of integrators must not define the divisional executive backbone.
- Ideally officers whose mandate includes way integration would appoint an
integrator, ordinarily not himself.
- Yet integrators must appoint their subordinates,
else they could not be expected to work with them.
∴ Non-root integrators answer to two superiors — both peers under a
further divisional superior, one an integrator and the other a
divisional officer — both of whom must extend the offer.
- Each offer echoes the other, and any acceptance echoes both.
- So the waysource integration branch entwines the divisional backbone.
/ Make the chief officer (at root) the only non-integrator who needs to
define his waycast content by reference and worry about signaling through his
way model.
- Rather make even him exempt by a rule that says: for a root stock, the way model
to copy from is that of is his appointed integrator.
- That integrator copies from nowhere, using only his defined local content.
- So it all works nicely and only integrators need content by reference
and model signaling.
- An integrator other than the root copies from the way model of his
integrational superior, not his divisional superior (viz. stock).
- So this is effectively a separate branch for integration purposes,
however it may be entwined with the divisional executive backbone.
definition of way parts
/ Defining what files comprise the content of the way part.
- The appointed integrator alone defines a way part because way-part definition itself
is a function of integration, viz. it may require dynamic changes.
- The files of the way part are defined by either or both of the following.
• Direct waycast inclusion
- This takes precedence over what follows.
• Reference to a local appointment offer for a subordinate integrator
/ Likely this would be placed in the integrator’s acceptance of appointment as such.
- The files defined are those given in the subordinate’s acceptance
of the appointment, if any.
- Any overlap (conflict) with the definition of an integrator of another branch
would, in itself, pose an integrity problem to be solved.
pooling of waysource
/ Rootward accumulation of effective waycast content for purposes of model compilation.
- Pooling occurs where the way part under integration is defined by reference.
: see `^*• Reference to a local appointment offer` @ `^*definition of way parts$`
- Transfer of referent files is made efficient by the use of distributed revision control.
- Revision control is used for this purpose alone by a specialized component
of the model compiler specific to integrators.
- Integrators other than root must therefore put their waycasts under revision control.
communication among integrators
: privately see also notebook:2021-6-3
- The interlinked way models of integrators together function as a message channel
for purposes of waysource integration.
- A standing difference in a model signals a problem and/or proposed solution.
\ / Therefore any extra-part way file of an integrator (intracast waysource outside
\ his charge) must be self-integrating (require no change to extracast waysource)
\ else its integration would interfere with official signals.
\\ no ∵ inclusion of merely personal files would alter public definition of way part
- The difference may include, or even comprise, commentary (comment carriers)
inserted into the files concerned.
protocol: The intended recipient and meaning depends on the particular files affected,
as follows.
• Inside the way part under charge
- Asking each subordinate integrator responsible for an affected file
to pull that part of the difference (commentary aside) into one of:
- his waycast, the file being among those he directly works; or
- his own way model, whence it would message further subordinates.
- Ordinarily this would be to correct some incoherence in the way part
involving files outside any one subordinate’s charge.
• Outside the way part under charge
- Asking the superior to pull the difference into any or either of:
- his waycast, where it affects a file he directly works; or
- his own way model, whence it would message either other
subordinates (peers of the sender), or a further superior.
- This might be to correct a compilation failure, or to inform the
superior of an integration problem he might otherwise have missed.