tag:support.multimarkdown.com,2013-02-12:/discussions/problems/1446-cross-references-not-working-in-pro-betaMultiMarkdown Software, LLC: Discussion 2017-11-05T19:46:22Ztag:support.multimarkdown.com,2013-02-12:Comment/365920652015-04-16T00:53:08Z2015-04-16T00:53:08ZCross references not working in Pro beta<div><p>Can you be more specific? They work just fine for me.</p>
<p>F-</p>
<h2><a href="#" class="anchor" name=""></a></h2>
<p>Fletcher T. Penney<br>
Manager, Founder<br>
MultiMarkdown Software, LLC<br>
<a href="mailto:admin@multimarkdown.com">admin@multimarkdown.com</a></p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/365920652015-04-16T11:33:13Z2016-03-16T10:53:43ZCross references not working in Pro beta<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/16/15 03:53, Fletcher
wrote:<br></div>
<blockquote type="cite">pre { width: 92%; margin: 10px 2%; padding:
5px 2%; background: #efefef; border: 1px solid #d6d6d6 } blockquote
{ margin-left: 0; padding-left: 1em; border-left: 5px solid #ccc; }
<table width="100%">
<tr>
<td>
<p>// Please reply above this line<br>
==================================================</p>
<p><b>From</b>: Fletcher (Support staff)</p>
<div>
<p>Can you be more specific? They work just fine for me.</p>
<p>F-</p>
<p>--<br>
Fletcher T. Penney<br>
Manager, Founder<br>
MultiMarkdown Software, LLC<br>
[email blocked]</p>
</div>
<div>
<p>On Wed, Apr 15 at 09:19 PM, Yitzhak Bar Geva wrote:</p>
<blockquote>
<div>
<p>Thought you might want to know. In-file links, called cross
refefences in the MMD syntax guide don't work in Pro Beta, Version
3.0b32 (32). To make sure, I tried in Composer Version 2.8 (58) and
they work OK.</p>
</div>
</blockquote>
</div>
</td>
</tr>
<tr>
<td>
<p>Having trouble reading this? View this discussion online:
<a href=
"http://support.multimarkdown.com/discussions/problems/1446-cross-references-not-working-in-pro-beta">
Cross references not working in Pro beta</a>.</p>
<p>Reply with #ignore to stop receiving notifications for this
discussion.</p>
</td>
</tr>
</table>
</blockquote>
<br>yitzhakbargevatag:support.multimarkdown.com,2013-02-12:Comment/365920652015-04-16T13:32:46Z2016-03-16T10:53:43ZCross references not working in Pro beta<div><p>MultiMarkdown Composer Pro (Beta) (3.0b32)</p>
<h1><a class="anchor" name="original-text-" href="#original-text-"></a>Original Text:</h1>
<h1><a class="anchor" name="software-del-defined-del-networking-explained" href="#software-del-defined-del-networking-explained"></a>Software
<del>Defined</del> Networking Explained</h1>
<p>The biggest problem explaining pure software networking is its
sheer simplicity. As Prof. Scott Shenker said, networking folks
pride themselves on mastering complexity, but lets give it a
shot.</p>
<p>We'll start with a simple analogy, a word processor. Most word
processors have a unique file format, understandable only to
themselves, but that's hardly a problem. Wherever we want to use a
file of that format, all we have to do is fire up the word
processor. There could easily be thousands or millions of copies of
that word processor throughout the world running at any given
moment. We'll call the universe using the file format a
<em>realm</em>. Obviously there can be other realms, other word
processors each with their specific file formats existing merrily
side-by-side.</p>
<p>Note that the users of word processor adhere to a protocol - a
mutually agreed upon common file format. The developers were free
to define the format and to change it at will. If the tomorrow the
developers change the file format, the users will not be adhering
to the updated protocol and can't process files in the new format
until they have compliant software, an updated version of the word
processor in this case.</p>
<p>Protocol? Without proposals, standards committees, yet clearly
all users of the file format <em>have agreed</em> as it were to use
that word processor, or conversely, all users of the word processor
<em>have agreed</em> to use that file format. The key to
flexibility in achieving uniform, agreed upon use of a common
format is loadable user space software, more commonly called
application software. The protocol is flexible, uniformity is
assured by distributing the updated application software.</p>
<p>The point here is that the entire world doesn't have to adapt a
common standard. The community of users is sufficient and there can
be unlimited coexisting communities. There is no reason for
networking to be any different.</p>
<p>The term <em>Protocol Wall</em> in our paper, <a href="http://bit.ly/1JHBCZu">Tearing Down the Protocol Wall with SDN</a>
denotes the barrier dividing between rigid, protocol bound
networking software accessible to experts alone on one side and
freely distributed, evolvable application software on the other
side accessible to the world at large. This paper shows how that
<em>Protocol Wall</em> can be toppled with network software
becoming application software unshackled from confining protocol
constraints. And, it's practically realizable.</p>
<p>Moving ahead with our analogy, say the word processor files are
packets, chunks of data which can be shipped around, processed,
merged or split up and that the word processor analogy is extended
to becoming a humongous distributed word processing application
encompassing its own networking strata functionally equivalent to
the conglomeration of switches, routers, kernel code etc.
comprising the networking strata which we're familiar. In short, an
application with networking or a network with an embedded
application. No difference since there is no <em>protocol
wall</em>. The application runs on the network of participating
nodes powered by their enormous pooled processing power.</p>
<p>Let's go over that again since it's essential to grasp the
concept. Start with running an application on a multi-core computer
in a single box (or tablet/cellphone). Now expand the box to
contain all the cores of the network nodes. Conceptually, it's
still one box but now with many more cores. The application
<em>runs</em> on the network. Saying that today's network devices
are capable of running application software is the same as saying
that today's computers are capable of running networking software.
In fact, they can live in the same box. Again: The network is the
application's processing platform just as the individual computer
was to the word processor.</p>
<p>Read [How Did We Get Here?][] to see how:</p>
<ol>
<li>Networking became so entangled and complex in the first
place.<br></li>
<li>Our minds got locked in to viewing networking as nothing more
than a computationally impotent transport mechanism and<br></li>
<li>We became dependent on outside suppliers.</li>
</ol>
<p>Next, the nitty‑gritty of how it works.</p>
<h2><a class="anchor" name="breaking-it-down-to-pieces" href="#breaking-it-down-to-pieces"></a>Breaking It Down to Pieces</h2>
<h2><a class="anchor" name="how-did-we-get-here-" href="#how-did-we-get-here-"></a>How Did We Get Here?</h2>
<p>Despite networking's dramatic progress in becoming more software
oriented in recent years, it pales in face of the pace of progress
in the world of software development. Network development remains
an esoteric art in the hands of a community of experts off limits
to the world at large. How did this come about?</p>
<h3>
<a class="anchor" name="how-come-networking-wasn-39-t-application-software-in-the-first-place-" href="#how-come-networking-wasn-39-t-application-software-in-the-first-place-">
</a>How Come Networking Wasn't Application Software in the First
Place?</h3>
<p>Had networking been user memory space loadable (=application)
code from the outset, networking would never have become a distinct
discipline. It would have been a branch of software like any other.
To understand that, we have to realize that networking's evolution
followed the pattern of early computers: Performance was of the
essence and that dictated its being a hardware oriented culture.
Embedding functionality in hardware necessitated developing
software according to strict protocol definitions so that different
vendors gear could interoperate. That was the situation of early
computers. Programs written on one manufacturer's computer could
not run on competitors' machines.<br>
What happened, perhaps inadvertently, was implicit acceptance of
the need to sacrifice performance in exchange for ease in writing
software. Performance on current generation hardware always lags
behind optimal operation on cutting edge hardware but ultimately
catches up . Even today we could improve performance by hand-coding
programs in assembly language. But who in their right mind would
invest such tremendous efforts for such minuscule marginal gains
and bind their programs to specific processors?! Well protocols are
a kind of universal assembly language dictating that networking
software be written in lockstep.</p>
<p>###Performance is not an impeding factor The context<br>
The question of whether networking could have been left to develop
freely as software without adherence to protocols raises a sinister
thought.</p>
<h3><a class="anchor" name="was-there-an-evil-hand-hand-behind-this-" href="#was-there-an-evil-hand-hand-behind-this-"></a>Was there an Evil
Hand[Hand] [Behind] This?</h3>
<p>Requiring protocols played into the hands of a select group of
network hardware manufacturers by necessitating use of dedicated
hardware. If it did occur to anyone that software networking could
enable most of that functionality on standard computers, they
didn't let that secret out of the box.</p>
<h1><a class="anchor" name="" href="#"></a></h1>
<p>Original Text Finished<br>
Removed:</p>
<h1><a class="anchor" name="-5912-55-" href="#-5912-55-"></a>{5912, 55}</h1>
<p>###Performance is not an impeding factor The context</p>
<h1><a class="anchor" name="_1" href="#_1"></a></h1>
<p>Removed Finished</p>
<h1><a class="anchor" name="inserted-" href="#inserted-"></a>Inserted:</h1>
<h1><a class="anchor" name="_2" href="#_2"></a></h1>
<p>Inserted Finished</p>
<h1><a class="anchor" name="result-" href="#result-"></a>Result:</h1>
<h1><a class="anchor" name="software-del-defined-del-networking-explained_1" href="#software-del-defined-del-networking-explained_1"></a>Software
<del>Defined</del> Networking Explained</h1>
<p>The biggest problem explaining pure software networking is its
sheer simplicity. As Prof. Scott Shenker said, networking folks
pride themselves on mastering complexity, but lets give it a
shot.</p>
<p>We'll start with a simple analogy, a word processor. Most word
processors have a unique file format, understandable only to
themselves, but that's hardly a problem. Wherever we want to use a
file of that format, all we have to do is fire up the word
processor. There could easily be thousands or millions of copies of
that word processor throughout the world running at any given
moment. We'll call the universe using the file format a
<em>realm</em>. Obviously there can be other realms, other word
processors each with their specific file formats existing merrily
side-by-side.</p>
<p>Note that the users of word processor adhere to a protocol - a
mutually agreed upon common file format. The developers were free
to define the format and to change it at will. If the tomorrow the
developers change the file format, the users will not be adhering
to the updated protocol and can't process files in the new format
until they have compliant software, an updated version of the word
processor in this case.</p>
<p>Protocol? Without proposals, standards committees, yet clearly
all users of the file format <em>have agreed</em> as it were to use
that word processor, or conversely, all users of the word processor
<em>have agreed</em> to use that file format. The key to
flexibility in achieving uniform, agreed upon use of a common
format is loadable user space software, more commonly called
application software. The protocol is flexible, uniformity is
assured by distributing the updated application software.</p>
<p>The point here is that the entire world doesn't have to adapt a
common standard. The community of users is sufficient and there can
be unlimited coexisting communities. There is no reason for
networking to be any different.</p>
<p>The term <em>Protocol Wall</em> in our paper, <a href="http://bit.ly/1JHBCZu">Tearing Down the Protocol Wall with SDN</a>
denotes the barrier dividing between rigid, protocol bound
networking software accessible to experts alone on one side and
freely distributed, evolvable application software on the other
side accessible to the world at large. This paper shows how that
<em>Protocol Wall</em> can be toppled with network software
becoming application software unshackled from confining protocol
constraints. And, it's practically realizable.</p>
<p>Moving ahead with our analogy, say the word processor files are
packets, chunks of data which can be shipped around, processed,
merged or split up and that the word processor analogy is extended
to becoming a humongous distributed word processing application
encompassing its own networking strata functionally equivalent to
the conglomeration of switches, routers, kernel code etc.
comprising the networking strata which we're familiar. In short, an
application with networking or a network with an embedded
application. No difference since there is no <em>protocol
wall</em>. The application runs on the network of participating
nodes powered by their enormous pooled processing power.</p>
<p>Let's go over that again since it's essential to grasp the
concept. Start vƭ</p></div>yitzhakbargevatag:support.multimarkdown.com,2013-02-12:Comment/365920652015-04-24T11:47:17Z2015-04-24T11:47:17ZCross references not working in Pro beta<div><p>I see your document, but I'm not clear on what isn't working as
you expect?</p>
<p>F-</p></div>Fletcher