Cross references not working in Pro beta
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.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Fletcher on 16 Apr, 2015 12:53 AM
Can you be more specific? They work just fine for me.
F-
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
2 Posted by yitzhakbargeva on 16 Apr, 2015 11:33 AM
3 Posted by yitzhakbargeva on 16 Apr, 2015 01:32 PM
MultiMarkdown Composer Pro (Beta) (3.0b32)
Original Text:
====
# Software <Del>Defined</Del> Networking Explained #
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.
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 *realm*. Obviously there can be other realms, other word processors each with their specific file formats existing merrily side-by-side.
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.
Protocol? Without proposals, standards committees, yet clearly all users of the file format *have agreed* as it were to use that word processor, or conversely, all users of the word processor *have agreed* 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.
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.
The term *Protocol Wall* in our paper, [Tearing Down the Protocol Wall with SDN](http://bit.ly/1JHBCZu) 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 *Protocol Wall* can be toppled with network software becoming application software unshackled from confining protocol constraints. And, it's practically realizable.
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 *protocol wall*. The application runs on the network of participating nodes powered by their enormous pooled processing power.
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 *runs* 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.
Read [How Did We Get Here?][] to see how:
1. Networking became so entangled and complex in the first place.
2. Our minds got locked in to viewing networking as nothing more than a computationally impotent transport mechanism and
3. We became dependent on outside suppliers.
Next, the nitty‑gritty of how it works.
## Breaking It Down to Pieces ##
## How Did We Get Here? ##
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?
### How Come Networking Wasn't Application Software in the First Place? ###
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.
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.
###Performance is not an impeding factor
The context
The question of whether networking could have been left to develop freely as software without adherence to protocols raises a sinister thought.
### Was there an Evil Hand[Hand] [Behind] This?
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.
====
Original Text Finished
Removed:
{5912, 55}
====
###Performance is not an impeding factor
The context
====
Removed Finished
Inserted:
====
====
Inserted Finished
Result:
====
# Software <Del>Defined</Del> Networking Explained #
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.
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 *realm*. Obviously there can be other realms, other word processors each with their specific file formats existing merrily side-by-side.
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.
Protocol? Without proposals, standards committees, yet clearly all users of the file format *have agreed* as it were to use that word processor, or conversely, all users of the word processor *have agreed* 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.
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.
The term *Protocol Wall* in our paper, [Tearing Down the Protocol Wall with SDN](http://bit.ly/1JHBCZu) 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 *Protocol Wall* can be toppled with network software becoming application software unshackled from confining protocol constraints. And, it's practically realizable.
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 *protocol wall*. The application runs on the network of participating nodes powered by their enormous pooled processing power.
Let's go over that again since it's essential to grasp the concept. Start vƭ
Support Staff 4 Posted by Fletcher on 24 Apr, 2015 11:47 AM
I see your document, but I'm not clear on what isn't working as you expect?
F-
Fletcher closed this discussion on 05 Nov, 2017 07:46 PM.