THE RIVER WILD A film review by Ben Hoffman Copyright 1994 Ben Hoffman
If there currently is a more talented, more versatile actress than Meryl Streep, I have no idea who that might be. Be it SOPHIE'S CHOICE, DEFENDING YOUR LIFE, FRENCH LIEUTENANT'S WOMAN, KRAMER VS KRAMER, SILKWOOD, MANHATTAN, or any of her other films, she is magnificent. It comes as no surprise then that in this film she is right on the believability target as the desperate mother and wife who steers a raft through the white-water rapids to save her family.
Gail (Streep), her husband, Tom (David Strathairn), and their son, Roarke (Joseph Mazzelllo), are white-water rafting on their vacation as David and Gail try to put the lost zest back into their marriage. Gail has spent her childhood on the river and knows every inch of it. She has even gone over the falls where the three rivers meet in a wicked, turbulent and very dangerous confluence ... but she was 18 then. Now, so many years later, she is called upon to save her family as she and her son race down the river in a raft with two robbers who are making an escape with a bagful of money and forcing Gail to get them to the border.
Kevin Bacon is properly mean as one of the robbers who befriends and charms young Roarke but who turns vicious when he kidnaps the family to aid in his escape.
The beautiful scenery, the rushing water with its churning waves, the raft going over several falls, and everyone hanging on for dear life as Gail maneuvers the raft around waves and boulders makes for an exceptionally fine thriller while all the time, Jerry Goldsmith's stirring music pumps up the action, keeping you glued to the edge of your seat. This is what action movies are all about.
 The script is by Denis O'Neill.
3.5 bytes 4 Bytes = Absolutely must see. 3 Bytes = Too good to be missed. 2 Bytes = So so. 1 Byte = Save your money.
Ben Hoffman
.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Week 2: Fusion 360
This week, we created personalized wax stamps using a program called Fusion 360. I had missed a few classes, so I watched an example video
and figured out how to use the program. I created a stamp that has my initials JL in cursive, and played around with the different tools in
Fusion 360 to add decorative elements to the body of my stamp. Making the model was really fun and the program was easy to use.
After designing the stamp, I sent the file to the 3D printer. I'm pretty happy with how my stamp turned out!
Stamp Makerbot File


Lorem ipsum dolor sit amet justo consectetuer adipiscing elit sit amet Suspendisse et justo Praesent.
Lorem ipsum dolor sit amet justo consectetuer adipiscing elit sit amet Suspendisse et justo Praesent.
Lorem ipsum dolor sit amet justo consectetuer adipiscing elit sit amet Suspendisse et justo Praesent.
There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable. If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidden in the middle of text.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Praesentium.
CEO & Managing Director
Head of Operations
HR Manager
Worker
© Copyright Forbes | All Rights Reserved.


A WORD COUNTER.WITH MUSIC😎😎😎😎😎😎😎😎#Vardaan By Ajey Nagar.Enjoy the music and count the words.
Import Notice-This Word Counter is in trail version till 10January|2021.So,Do not forget to give your feed back to our email by contact us page in our website.


| RFC 8700 | Fifty Years of RFCs | April 2021 |
| Flanagan | Informational | [Page] |
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8700.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The RFC Series began in April 1969 with the publication of "Host Software" by Steve Crocker. The early RFCs were, in fact, requests for comments on ideas and proposals; the goal was to start conversations rather than to create an archival record of a standard or best practice. This goal changed over time, as the formality of the publication process evolved and the community consuming the material grew. Today, over 8500 RFCs have been published, ranging across best practice guidance, experimental protocols, informational material, and, of course, Internet standards. Material is accepted for publication through the IETF, the IAB, the IRTF, and the Independent Submissions streams, each of which have clear processes on how drafts are submitted and potentially approved for publication as an RFC. Ultimately, the goal of the RFC Series is to provide a canonical source for the material published by the RFC Editor and to support the preservation of that material in perpetuity.¶
The RFC Editor as a role came a few years after the first RFC was published. The actual date the term "RFC Editor" was first used is unknown, but it was formalized by [RFC0902] in July 1984; Jon Postel, the first RFC Editor, defined the role by his actions and later by defining the initial processes surrounding the publication of RFCs. What is certain is that the goal of the RFC Editor is to produce documents that are readable, clear, consistent, and reasonably uniform, and that the archival record of what has been published is maintained.¶
Change does come to the Series, albeit slowly. First, we saw the distribution method change from postal mail to FTP and then to email. RFCs could not be distributed electronically in the beginning, as the means to do that distribution would not be defined until years after the first RFC was "published". Not all early RFCs were even created electronically; some were written out by hand or on a typewriter. Eventually, the process for creating RFCs became more structured; authors were provided guidance on how to write an RFC. The editorial effort went from Steve Crocker to a more official model with a designated editor, Jon Postel, and later to a team of five to seven individuals. The actual editing and publishing work split from the service for registration of protocol code points. The whole RFC Editor structure was reviewed [RFC4844], refined [RFC5620], and refined again [RFC6635]. And, in the last few years, the process to change the format of the RFC documents themselves has started [RFC7990].¶
This is evolution; and the Series will continue to be adapted in order to meet the needs and expectations of the implementers, operators, historians, and community of authors that uses the RFC Series. These changes will always be balanced against the core mission of the Series: to maintain a strong, stable, archival record of technical specifications, protocols, and other information relevant to the Advanced Research Projects Agency Network (ARPANET) and Internet networking communities.¶
There is more to the history of the RFC Series than can be covered in this document. Readers interested in earlier perspectives may find the following RFCs of particular interest. These RFCs focus on the enormous contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and first RFC Editor:¶
In this document, the history of the Series is viewed through the eyes of several individuals who have been a part of shaping it. Narratives of this nature offer a limited perspective on events; there are almost certainly other viewpoints, memories, and perspectives on events that are equally valid and would reflect a different history. So, while these retrospectives are enormously valuable and provide an insight to events of the day, they are just one lens on the history of the RFC Series.¶
Steve Crocker, author of [RFC0001], offers his thoughts on how and why the Series began. Leslie Daigle, a major influence in the development of the RFC Editor model, offers her thoughts on the change of the RFC Editor to a stronger, contracted function. Nevil Brownlee, Independent Submissions Editor from 2010 through February 2018, shares his view on the clarification of the Independent Stream (IS) and its transition upon the retirement of Bob Braden from the position. As the current RFC Series Editor, I will put my thoughts in on the most recent changes in formalizing the digital preservation of the Series, the process to modernize the format while respecting the need for stability, and my thoughts on the next fifty years of RFCs.¶
This document updates the perspectives offered in [RFC2555] and [RFC5540].¶
| Marker | Date | Event |
|---|---|---|
| [RFC0001] | April 1969 | First RFC published |
| [RFC0114] | April 1971 | First distribution of RFCs over the network |
| [RFC0433] | December 1972 | First mention of the Czar of Socket Numbers and the proposal for a formal registry |
| [RFC0690] | June 1975 | Relationship starts between the Information Sciences Institute (ISI) and the RFC Editor (judging by Jon Postel's affiliation change) |
| [RFC0748] | April 1977 | First April 1st RFC published |
| [IETF1] | January 1986 | First Internet Engineering Task Force (IETF) meeting |
| [IAB-19880712] | July 1988 | IAB approved the creation of an Internet-Draft series |
| [RFC1122][RFC1123] | December 1988 | First major effort to review key specifications and write applicability statements |
| [RFC1083] | October 1989 | Three-stage standards process first defined |
| [RFC1150] | March 1990 | FYI sub-series started |
| [RFC1311] | March 1992 | STD sub-series started |
| [RFC1818] | August 1995 | BCP sub-series started |
| [RFC-ONLINE] | approx. 1998 | RFC Online Project to restore early RFCs that were "lost" started |
| [RFC2441] | 15 October 1998 | Jon Postel's death |
| [RFC4844] | July 2007 | RFC Series administrative structure documented |
| [RFC4846] | July 2007 | Independent Submission document stream is formalized |
| [RFC5620] | August 2009 | RFC Editor organization officially established as RFC Series Editor, Independent Submission Editor, RFC Production Center, and RFC Publisher |
| [ISI-to-AMS] | October 2009 | Transition of RFC Production Center and RFC Publisher starts from Information Sciences Institute (ISI) to Association Management Solutions (AMS) |
| [RFC5540] | January 2010 | Bob Braden retires from RFC Editor |
| [RFC5743] | December 2009 | Internet Research Task Force document stream formalized |
| [RFC-ONLINE] | approx. 2010 | RFC Online Project to restore early RFCs that were "lost" finished |
| [RFC6360] | August 2011 | FYI sub-series ended |
| [RFC6410] | October 2011 | Two-stage standards process formalized |
| [RFC6635] | June 2012 | Updated responsibilities of RFC Series allocated to RFC Series Editor, RFC Production Center, and RFC Publisher |
| [RFC6949] | May 2013 | RFC format change project started |
| [RFC8153] | April 2017 | RFCs no longer printed to paper upon publication |
(This is a revision of material included more than 30 years ago in [RFC1000].)¶
The Internet community now includes millions of nodes and billions of users. It owes its beginning to the ARPANET, which was once but a gleam in the eyes of J. C. R. Licklider, Bob Taylor, and Larry Roberts of the Advanced Research Projects Agency (ARPA). While much of the development proceeded according to plan, the initial design of the protocols and the creation of the RFCs was largely accidental.¶
The procurement of the ARPANET was initiated in the summer of 1968; remember Vietnam, flower children, etc.? There had been prior experiments at various ARPA sites to link together computer systems, but this was the first version to explore packet switching as a core part of the communication strategy. ("ARPA" didn't become "DARPA" (Defense Advanced Research Projects Agency) until 1972. It briefly changed back to ARPA in 1993 and then back again to DARPA.) The government's Request for Quotations (RFQ) called for four packet- switching devices, called Interface Message Processors ("IMPs"), to be delivered to four sites in the western part of the United States: University of California, Los Angeles (UCLA); SRI International (Stanford Research Institute) in Menlo Park, CA; University of California, Santa Barbara (UCSB); and the University of Utah in Salt Lake City. These sites were running a Scientific Data Systems (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10, respectively. These machines not only had different operating systems, but even details like character sets and byte sizes varied. Other sites would have further variations.¶
The focus was on the basic movement of data. The precise use of the ARPANET was not spelled out in advance, thus requiring the research community to take some initiative. To stimulate this process, a meeting was called in August 1968 with representatives from the selected sites, chaired by Elmer Shapiro from SRI. Based on Shapiro's notes from that meeting, the attendees were Dave Hopper and Jeff Rulifson from SRI; Glen Culler and Gordon Buck from Santa Barbara; R. Stephenson, C. Stephen Carr, and W. Boam from Utah; Vint Cerf and me from UCLA; and a few others from potential future sites.¶
That first meeting was seminal. We had lots of questions. How would IMPs and "hosts" (I think that was the first time I was exposed to that term) be connected? What would hosts say to each other? What applications would be supported? The only concrete answers were remote login as a replacement for dial-up, telephone-based interactive terminal access, and file transfer, but we knew the vision had to be larger. We found ourselves imagining all kinds of possibilities: interactive graphics, cooperating processes, automatic database query, electronic mail, etc., but no one knew where to begin. We weren't sure whether there was really room to think hard about these problems; surely someone senior and in charge, likely from the East, would be along by and by to bring the word. But we did come to one conclusion: we ought to meet again. Over the next several months, we met at each of our sites, thereby setting the precedent for regular face-to-face meetings. We also instantly felt the irony. This new network was supposed to make it possible to work together at a distance, and the first thing we did was schedule a significant amount of travel.¶
Over the next several months, a small, fairly consistent set of graduate students and staff members from the first four sites met. We used the term Network Working Group (NWG) to designate ourselves. This was the same term Elmer Shapiro had used when he convened our first meeting, although it had been used until that point to refer to the principal investigators and ARPA personnel: senior people who had been planning the network. Our group was junior and disjointed from the prior group, except, of course, that each of us worked for one of the principal investigators.¶
The first few meetings were quite tenuous, primarily because we weren't sure how narrow or expansive our goals should be. We had no official charter or leadership, and it remained unclear, at least to me, whether someone or some group would show up with the official authority and responsibility to take over the problems we were dealing with. Without clear definition of what the host-IMP interface would look like, or even a precise definition of what functions the IMP would provide, we focused on broader ideas. We envisioned the possibility of application-specific protocols, with code downloaded to user sites, and we took a crack at designing a language to support this. The first version was known as DEL, for "Decode-Encode Language" and a later version was called NIL, for "Network Interchange Language".¶
In late 1968, Bolt Beranek and Newman (BBN) in Cambridge, MA won the contract for the IMPs and began work in January 1969. A few of us flew to Boston in the middle of February to meet the BBN crew. The BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein, Ben Barker, Will Crowther, Bernie Cosell, and Dave Walden. They were organized, professional, and focused. Their first concern was how to meet their contract schedule of delivering the first IMP to UCLA at the beginning of September and how to get bits to flow quickly and reliably. The details of the host-IMP interface were not yet firm; the specification came a few months later as BBN Report 1822. In particular, BBN didn't take over our protocol design process, nor did any other source of authority appear. Thus, we doggedly continued debating and designing the protocols.¶
A month later, our small NWG met in Utah. As the meeting came toward an end, it became clear to us that we should start writing down our discussions. We had accumulated a few notes on the design of DEL and other matters, and we decided to put them together in a set of notes. We assigned writing chores to each of us, and I took on the additional task of organizing the notes. Though I initiated the RFCs, my role was far less than an editor. Each of the RFCs were numbered in sequence. The only rule I imposed was the note had to be complete before I assigned a number because I wanted to minimize the number of holes in the sequence.¶
I tried a couple of times to write a note on how the notes would be organized, but I found myself full of trepidation. Would these notes look as if we were asserting authority we didn't have? Would we unintentionally offend whomever the official protocol designers were? Finally, unable to sleep, I wrote a few humble words. The basic ground rules were that anyone could say anything and that nothing was official. And to emphasize the point, I used Bill Duvall's suggestion and labeled the notes "Request for Comments". I never dreamed these notes would eventually be distributed through the very medium we were discussing in these notes: talk about Sorcerer's Apprentice! (See [APPRENTICE].)¶
After BBN distributed the specification for the IMP hardware and software interface to the initial ARPANET sites, our attention shifted to low-level matters. The ambitious ideas for automatic downloading of code evaporated. It would be several years before ideas like mobile code, remote procedure calls, ActiveX, JAVA, and Representational State Transfer (RESTful) interfaces appeared.¶
Over the spring and summer of that year, we grappled with the detailed problems of protocol design. Although we had a vision of the vast potential for intercomputer communication, designing usable protocols was another matter. We knew a custom hardware interface and a custom software addition in the operating system was going to be required for anything we designed, and we anticipated these would pose some difficulty at each of the sites. We looked for existing abstractions to use. It would have been convenient if we could have made the network simply look like a regular device, e.g., a tape drive, but we knew that wouldn't do. The essence of this network was peer-to-peer cooperation among the machines and the processes running inside them, not a central machine controlling dependent devices. We settled on a virtual bit stream layer as the basic building block for the protocols; but even back then, we knew that some applications like voice might need to avoid that layer of software. (Why a virtual bit stream instead of a virtual byte stream? Because each computer had its own notion of how many bits were in a byte. 8-bit bytes didn't become standard until a few years later.)¶
Over the next two years, we developed, exchanged, and implemented ideas. I took a leave from UCLA in June 1971 to spend time working at ARPA. Jon Postel took over the care and feeding of the RFCs, evolving the process and adding collaborators over the next twenty- seven years.¶
The rapid growth of the network and the working group also led to a large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at the MIT Research Establishment (MITRE) took on the task of indexing them. That seemed like a large task then, and we could have hardly anticipated seeing more than 1000 RFCs several years later and the evolution toward Internet-Drafts yet later.¶
When we first started working on the protocols, the network did not exist. Except for our occasional face-to-face meetings, RFCs were our only means of communication. In [RFC0003], I set the bar as low as possible:¶
Making the RFCs informal was not only a way of encouraging participation; it was also important in making the communication effective. One of the early participants said he was having trouble writing and sending an RFC because his institution wanted to subject them to publication review. These are not "publications", I declared, and the problem went away. Another small detail, handled instinctively and without debate, was the distribution model. Each institution was required to send a copy directly to each of the other handful of participating institutions. Each institution handled internal copies and distribution itself. Submission to a central point for redistribution was not required so as to minimize delays. SRI's Network Information Center, however, did maintain a central repository of everything and provided an invaluable record.¶
We didn't intentionally set out to challenge the existing standards organizations, but our natural mode of operation yielded some striking results. The RFCs are open in two important respects: anyone can write one for free and anyone can get them for free. At the time, virtually everyone in the ARPANET community was sponsored by the government, so there was little competition and no need to use documents as a way of raising money. Of course, as soon as we had email working on the ARPANET, we distributed RFCs electronically. When the ARPANET became just a portion of the Internet, this distribution process became worldwide. The effect of this openness is often overlooked; even now, students and young professionals all over the world have been able to download RFCs, learn about the technology within, and in turn, build the most amazing software. (They are also a fantastic resource for historians.)¶
Where will it end? The ARPANET begat the Internet, and the underlying technology transitioned from the original host-host protocol to TCP/IP. But, the superstructure of protocol layers, community-driven protocol design, and RFCs continued. Through the changes in physical-layer technology, resulting in speed increases from thousands to billions of bits per second, and similarly from thousands to billions of users, this superstructure, including the RFCs, has continued to serve the community. All of the computers have changed, as have all of the transmission lines, but the RFCs march on. Maybe I'll write a few words for RFC 10,000.¶
Quite obviously, the circumstances have changed. Email and other media are most often used for the immediate exchange of inchoate thoughts. Internet-Drafts are the means for exchanging substantial, albeit sometimes speculative, content, while RFCs are reserved for fully polished, reviewed, edited, and approved specifications. Comments to RFCs are not requested, although usage-related discussions and other commentary on mailing lists often take place nonetheless. Rather than bemoan the change, I take it as a remarkable example of adaptation. RFCs continue to serve the protocol development community. Indeed, they are the bedrock of a very vibrant and productive process that has fueled and guided the Internet revolution.¶
As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role of RFC manager in 1971 when Steve left UCLA for ARPA. Jon took on this role in addition to his subsequent "numbers Czar" responsibilities. Initially, his focus was largely on assigning RFC numbers to aspiring writers, but with time, and as the standardization of the ARPANET and Internet protocols continued apace, he began to serve in an editorial capacity. Moreover, as an accomplished software engineer, he had opinions about technical content in addition to writing style and did not hesitate to exercise editorial discretion as would-be published authors presented their offerings for his scrutiny. As the load increased, he recruited additional "volunteer" talent, most notably Joyce K. Reynolds, a fellow researcher at USC/ISI. Over the ensuing years, he also drafted Robert (Bob) Braden onto the team, and when Jon unexpectedly passed away in October 1998 (see [RFC2468]), Joyce and Bob undertook carrying on with the RFC work in his stead, adding Sandy Ginoza to the team. During the period when Jon and Joyce worked closely together, Joyce would challenge me to tell which edits had been made by Jon and which by her. I found this impossible, so aligned were they in their editorial sensibilities. Sadly, three of these tireless Internauts have passed on, and we have only the product of their joint work and Sandy Ginoza's and others' corporate memory by which to recall history.¶
I was the chair of the Internet Architecture Board, the board responsible for the general oversight of the RFC Series, at a particular inflection point in the evolution of all Internet technology institutions. To understand what we did, and why we had to, let me first paint a broader picture of the arc of these institutions.¶
Like many others who were in decision-making roles in the mid '00s, I wasn't present when the Internet was born. The lore passed down to me was that, out of the group of talented researchers that developed the core specifications and established the direction of the Internet, different individuals stepped up to take on roles necessary to keep the process of specification development organized and open. As the work of specification expanded, those individuals were generally supported by organizations that carried on in the same spirit. This was mostly Jon Postel, managing the allocation and assignment of names and numbers, as well as working as the editor of RFCs, but there were also individuals and institutions supporting the IETF's Secretariat function. By the late 20th century, even this model was wearing thin; the support functions were growing, and organizations didn't have the ability to donate even more resources to run them. In some cases (IANA), there was significant industry and international dependence on the function and its neutrality.¶
The IETF, too, had grown in size, stature, and commercial reliance. This system of institutional pieces "flying in formation" was not providing the kind of contractual regularity or integrated development that the IETF needed. People who hadn't been there as the institutions developed, including IETF decision makers, didn't innately understand why things "had to be the way they were" and were frustrated when trying to get individual systems updated for new requirements as well as better integrated across the spectrum of activities.¶
Internet engineering had expanded beyond the point of being supportable by a loosely coupled set of organizations of people who had been there since the beginning and knew each other well. New forms of governance were needed along with a rationalized funding model. The IANA function was absorbed into a purpose-built international not-for-profit organization. The IETF stepped up to manage its own organizational destiny, creating the IETF Administrative Support Activity (IASA), and the Secretariat became one of its contracted functions.¶
This left the RFC Editor function as an independent effort supported by the Internet Society.¶
That independent nature was necessary for the historic role of the RFC Series in considering all technical contributions. But, at that inflection point in the Series' history, it needed a new governance and funding model, just as the other organizations supporting Internet technical specification had. Also, the IETF leadership had some concerns it felt needed to be addressed in its own technical publication stream. While the RFC Series had been established before there was an IETF, and had historically continued to have documents in it that didn't originate from the IETF, the IETF was its largest and most organized contributor. There was no particular organization of independent contributors. Equally, the funding for the RFC Editor was at that point coming from the Internet Society in the guise of "support for the IETF". For people who hadn't been involved with the institution from the outset, it was pretty easy to perceive the RFC Series uniquely as the IETF's publication series. So, the challenge was to identify and address the IETF's issues, along with governance and funding, without sacrificing the fundamental nature of the RFC Series as a broader-than-IETF publication series.¶
To give a sense of the kind of tensions that were prevalent, let me share that the one phrase that stuck in my mind from those discussions was "push to publish". There were those in IETF leadership who felt that it would significantly reduce costs and improve timeliness if an RFC could be published by, literally, pushing a button on a web interface the moment it was approved by the IESG. It would also, they argued, remove the specification issues being introduced by copy editors that were hired as occasional workers to help with improving publication rates but who weren't necessarily up to speed on terms of art in technical specifications. (There were some pretty egregious examples of copy editors introducing changes that significantly changed the technical meaning of the text that I forbear from citing here; let's just say it wasn't strictly a problem of Internet engineers getting uptight about their cheese being moved.) While "push to publish" would have addressed those issues, it would not have addressed the loss of clarity from the many significant text improvements copy editors successfully introduced, or the fact that not all RFCs are approved by the IESG.¶
Institutionally, it was clear that the target was to have the RFC Editor function governance within the reach of the Internet technical community (as opposed to any particular private organization) without tying it specifically to the IETF. That was reasonably achievable by ensuring that the resultant pieces were established under the oversight of the IAB (which is, itself, independent of the IETF even as it is supported by the IASA organization).¶
The IETF worked on a document outlining functional requirements for its technical specification publication. This could have been useful for establishing its own series, but it also was helpful in establishing awareness of the challenges in document publishing (it always looks easy when you haven't thought about it) and also in laying the groundwork for dialogue with the RFC Editor. The requirements document was published as [RFC4714] as an Informational RFC that stands today to provide guidance in the editing processes surrounding IETF publications.¶
There was still, however, a certain lack of clarity about responsibilities for making decisions and changes in the RFC Series itself. To that end, I and the IAB worked with the various involved parties to produce [RFC4844]. That document captured the RFC Series mission (for a purpose greater than IETF technical specification publication) as well as the roles and responsibilities of the parties involved. The RFC Editor is responsible for ensuring the implementation of the mission. The IAB continues to have oversight responsibilities, including policy oversight, which it could act on by changing the person (organization) in the role of RFC Editor. At the same time, operational oversight was migrated to the IASA support function of the IETF (and IAB).¶
The discussions, and the resulting publication of [RFC4844], allowed greater visibility into and commitment to the RFC Series as a general Internet publication. It also meant that subsequent adjustments could be made as requirements evolved; the responsible parties are clearly identified.¶
Arguably starting in 2006 with [RFC4714], the IAB and the IETF community spent some time in the mid-'00s evolving the structure of the RFC Series. This work included defining how those groups that published into the RFC Series (initially including the IETF, the IAB [RFC4845], and the Independent Submissions Stream [RFC4846], and later growing to include the IRTF [RFC5743]) would handle approving documents to be published as RFCs. In 2009, the IAB published "RFC Editor Model (Version 1)" [RFC5620]. In this model, a new role was created within the RFC Editor: the RFC Series Editor (RSE). This individual would oversee RFC publishing and development while leaving the process for approving documents for publication outside his or her mandate. While, arguably, this was a role long filled by people like Jon Postel, Bob Braden, and Joyce Reynolds, [RFC5620] saw the role of RFC Series Editor defined in such a way as to distinctly separate it from that of the Independent Submissions Editor (ISE).¶
Before 2009, the RFC Editor could accept "Independent" submissions from individuals and, if they were judged significant, publish them as RFCs; the Independent Stream was set up to continue that function. From February 2010 through February 2018, I was the ISE. After reading [RFC4846], I went on to develop the Independent Stream (IS).¶
First, I spent several days at the RFC Production Center at the Information Sciences Institute (ISI) in Marina Del Ray with the RFC Editor (Bob Braden), Sandy Ginoza, and Alice Hagens so as to learn how RFCs were actually edited and published. All RFCs reach the Production Center as Internet-Drafts; they are copy edited until the edited version can be approved by its authors (AUTH48). At any stage, authors can check their draft's status via the RFC Editor website.¶
For the Independent Submissions, Bob kept a journal (a simple ASCII file) of his interactions with authors for every draft, indexed by the draft name. Bob also entered the Independent drafts into the RFC Editor database so that authors could track their draft's status. After my few days with his team at ISI, he handed that journal (covering about 30 drafts) over to me and said, "Now it's over to you!"¶
I began by following in Bob's footsteps, maintaining a journal and tracking each draft's status in the RFC Editor database. My first consideration was that every serious Internet-Draft submitted needed several careful reviews. At that time, if the ISE knew of suitable reviewers, he or she could simply ask them. Otherwise, if the draft related to an IETF or IRTF Working Group, the ISE could ask Working Group Chairs or Area Directors to suggest reviewers. The Independent Submissions Editorial Board (Ed Board) was another place the ISE could request reviewers from. My experience with reviewers was that most of those I approached were happy to help.¶
Most drafts were straightforward, but there were some that needed extra attention. Often, a draft requested IANA code points, and for that, IANA was always quick to offer help and support. Code points in some IANA registries require Expert Review [RFC8126]; sometimes the interactions with Expert Reviewers took quite a long time! Again, sometimes a draft seemed to fit better in the IETF Stream; for these, I would suggest that the draft authors try to find an Area Director to sponsor their work as an individual submission to the IETF Stream.¶
After my first few years as ISE, the IETF Tools Team developed the Datatracker [DATATRACKER] to show draft status and perform all the "housekeeping" tasks for all of the streams. At that stage, I switched to using the Datatracker rather than the RFC Editor database.¶
Once a draft has been reviewed and the authors have revised it in dialogue with their reviewers, the ISE must submit that draft to the IESG for an "IESG Review" [RFC5742]. Overall, each IS draft benefited from discussions (which were usually simple) with my Ed Board and the IESG. A (very) few were somewhat controversial; for those, I was able to work with the IESG to negotiate a suitable "IESG Statement" and/or an "ISE Statement" to make it clear why the ISE published the draft.¶
One rather special part of the Independent Stream is the April 1st RFCs. These are humorous RFCs that have no formal review and approval process. The authors must send them directly to the ISE or the RFC Editor. Only a few of them can be published each year, and each is reviewed by the ISE and the RSE. Bob Braden's criteria for April 1st drafts were:¶
They must relate to the Internet (like all drafts).¶
Their readers should reach the end of page two before realizing it is an April 1st RFC.¶
They must actually be funny!¶
April 1st RFCs have a large following, and feedback from the Internet community on April 1st of each year has been enthusiastic and quick!¶
159 RFCs were published in the Independent Stream during my eight years as ISE. Over those eight years, I worked with most of their authors and often met with them at IETF meetings. For me, that was a very rewarding experience, so I thank all those that contributed. During those eight years, I also worked with most of the IESG members, who all also gave me a lot of helpful interaction. Lastly, I've always enjoyed working with the RSE and all the staff of the RFC Production Center. The IETF (as a whole) is very fortunate to have such an effective team of talented professional staff.¶
When I joined ISI, shortly after Jon Postel passed away, the RFC Editor model as we know it today (as defined in [RFC5620] and as obsoleted by [RFC6548] and [RFC6635]) did not exist. The RFC Editor functioned as one unit: there was no RSE, Production Center, Publisher, or Independent Submissions Editor. All of these roles were performed by the "RFC Editor", which was comprised of four individuals: Bob Braden, Joyce Reynolds, a part-time student programmer, and me.¶
Bob provided high-level guidance and reviewed Independent Submissions. While Bob was a researcher in "Div 7" (Networking) at ISI, ostensibly, the percentage of time he had for the RFC Editor was 10%, but he invested much more time to keep the Series running. He pitched in where he could, especially when processing times were getting longer; at one point, he even NROFFed a couple of RFCs-to-be.¶
Joyce was a full-time ISI employee. However, while continuing to ensure RFCs were published, she was also serving as a User Services Area Director and a keynote speaker about the Internet, and she was also temporarily on loan to IANA for 50% of her time while IANA was getting established after separating from ISI. The student programmer performed programming tasks as requested and was, at the time, responsible for parsing MIBs.¶
I was a full-time staffer and had to quickly learn the ropes so RFCs would continue to be published. My primary tasks were to manage the publication queue, format and prepare documents for Joyce's review, carry out AUTH48 once Joyce completed her review, and publish, index, and archive the RFCs (both soft and hard copies).¶
The workload increased significantly over the next few years. As the workload increased, the RFC Editor reacted and slowly grew their staff over time. To understand the team growth, let's first take a look at the publication rates throughout history. The table below shows average annual publication rates during 5-year periods.¶
| Years | Avg. Pubs per Year |
|---|---|
| 1969 - 1972 | 80 |
| 1973 - 1977 | 55 |
| 1978 - 1982 | 20 |
| 1983 - 1987 | 39 |
| 1988 - 1992 | 69 |
| 1993 - 1997 | 171 |
| 1998 - 2002 | 237 |
| 2003 - 2007 | 325 |
| 2008 - 2012 | 333 |
| 2013 - 2017 | 295 |
There were significant jumps in the publication rates in the '90s and onward, with the number of publications almost doubling between 1993 and 2007. The annual submission count surpassed the 300 mark for the first time in 2004 and reached an all-time high of 385 in 2011. The submission rate did not drop below 300 until 2016 (284).¶
As the submissions grew, the RFC Editor experienced growing pains. Processing times began to increase as the existing staff was unable to keep up with the expanding queue size. In an attempt to reduce the training hump and to avoid permanently hiring staff in case the submission burst was a fluke, ISI brought on temporary copy editors; this way, the staff could easily be resized as needed. However, as Leslie noted, this didn't work very well. The effects of the experiment would be lasting, as this led to a form of the process we have now, where the RFC Editor asks more questions during AUTH/AUTH48 and technical changes require approval from the relevant Area Directors or stream managers, depending on the document stream. These changes added to the workload and extended publication times; many often now jokingly refer to AUTH48 as the authors' "48 days", "48 weeks", etc.¶
In addition to the increase in document submissions, we engaged in tools testing and went through several editorial process changes. Because of the lesson learned with temporary copy editors, our team grew to be more permanent. While we added other editors in between, two additions are of particular interest, as they experienced much of the RFC Editor's growing pains, helped work us out of a backlogged state, shaped the RFC Editor function, and are still with the team today: Alice Russo joined the team in 2005 and Megan Ferguson joined us in 2007.¶
With the understanding that the record-breaking number of submissions was not an anomaly, we made significant upgrades to the infrastructure of the RFC Editor function to facilitate document tracking and reporting. For example, the illustrious "black binder" (an actual 3-ring binder used to track RFC number assignment), a manually edited HTML file for the queue page, and a Rube Goldberg set of text files and scripts that created queue statistics, all were eventually replaced; an errata system was proposed and implemented; and XML became a newly accepted source file.¶
In 2009, [RFC5620] was published, introducing the initial version of the RFC Editor model we have now. While it was published in 2009, it did not go into effect until 2010, when the RFC Editor project as I knew it was disbanded and divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions Editor (ISE), RFC Production Center (RPC), and the Publisher function. In addition, the RFC Series Advisory Group (RSAG) was created to "provide expert, informed guidance (chiefly, to the RSE) in matters affecting the RFC Series operation and development" [RSAG].¶
In 2010, the RPC and Publisher contracts were awarded to Association Management Solutions (AMS). There, we started with three existing team members (Alice Russo, Megan Ferguson, and me), and we were pleased to be joined by Lynne Bartholomew and Rebecca VanRheenen, new colleagues to anchor us in the AMS office.¶
I was wary of this model and was especially worried about the hole Bob Braden's departure would create. Luckily for us, Bob Braden provided wise counsel and insight during the transition (and beyond). He gave the staff transitioning to AMS particularly helpful parting words, "keep the RFCs coming", and that is what we did.¶
AMS embraced the RFC Series and helped us quickly get set up on new servers. The RFC Production Center and Publisher were now part of the AMS family and it was all hands on deck to make sure the transition went smoothly to minimize the impact on document processing.¶
Our focus during transition was to 1) keep the trains running; that is, we wanted to get ourselves up and running with minimal down time, and 2) work with the Transitional RSE (a role that concluded before the transition ended), the ISE (Nevil Brownlee), RSAG, and the IETF Administrative Director (IAD) to better understand and implement the newly defined RFC Editor model.¶
Though some portions of the transition were challenging and lasted longer than expected, the Acting RSE (Olaf Kolkman) officially handed the reins over to the new RSE (Heather Flanagan) in 2012. She had to jump in, learn the RFC Editor and IETF culture, and work through a backlog of issues that had been left unattended.¶
Two of the backlogged issues were so old that they were ones someone had asked me about at my first IETF meeting: When was the RFC Editor going to allow non-ASCII characters in RFCs? When would the RFC Editor adopt a more modern publication format?¶
At that time, while we understood the desire to move toward supporting a broader range of character sets and having more-modern outputs, we also routinely received emails from individuals requesting that we send them plaintext files (instead of pointing them to the website) because their Internet access was limited. We also regularly received complaints from users of <https://www.rfc- editor.org> whenever something on the site didn't work correctly with their older browsers. In short, we could not advance without leaving a large number of users behind.¶
However, we now find ourselves on the precipice of change. The next few years promise to be exciting for the RFC Series as we transition from publishing plaintext, ASCII-only files to publishing multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both non-ASCII characters and SVG art.¶
Interestingly enough, I find that the RFC Editor has been in an almost constant state of change since I joined the team, even though the goal of the RFC Editor remains the same: to produce archival quality RFCs in a timely manner that are easily accessible for future generations.¶
As Steve Crocker mentioned, the Series began with goals of communication over formality and openness over structure. As the Internet has grown and become a pervasive, global construct, we still aim for openness and communication, but recognize that for protocols and other information to support interoperability, there must be points of stability to build from. Everyone, from small-time app developers to multi-billion dollar companies, is on the same footing. Anyone should be able to look back at a point in time and understand what was done and why.¶
While the informality has given way to increased structure, the openness and solid foundation that the Series provides must continue. With that in mind, what does the future hold for the next fifty years of RFCs?¶
The RFC Editor exists to edit, publish, and maintain an archive of documents published in the RFC Series. A proper digital archive, however, is more than just saving RFCs to disk and making sure the disks are backed up; the field of digital preservation has grown and transformed into an industry in and of itself. "Digital Preservation Considerations for the RFC Series" [RFC8153] reviews what a digital archive means today and describes ways to support the archive into the future. It also recommends ways for the RFC Editor to take advantage of those organizations that specialize in this field.¶
The future of digital preservation, as far as the RFC Series is concerned, will mean both finding new partners that can absorb and archive RFCs into a public, maintained digital archive and reviewing the RFC format to ensure that the published documents are archivable according to whatever the industry best practice is over time.¶
RFCs have been digital documents since very early in the days of the Series. While not always published in US-ASCII, that format has been the canonical format for decades. The fact that this format has lasted through so much evolution and change is remarkable.¶
Unfortunately, the US-ASCII format does not extend enough to meet the expectations and requirements of many users today. The entire field of online document presentation, consumption, and preservation has, in some cases, only been invented years after the first RFC was published. While it can be (and has been) argued that those newer fields and their tools have not had a chance to stand the test of time, the RFC Series Editor (in consultation with the community) started a concerted effort in 2012 to bring the RFC Series into alignment with a new array of possibilities for preservation and display.¶
Information on the RFC format project and the initial reasoning and requirements for the changes underway can be found in [RFC7990]. With the advent of these changes, the door has been opened to consider further changes in the future as the specifications for archiving digital material evolves, and as the expectation of web development advances.¶
In the eyes of many, particularly within the IETF, the RFC Series is synonymous with the IETF. While the Series itself predates the IETF by eighteen years, over time, the IETF has become the source of the majority of documents submitted for publication to the RFC Editor. The policies developed for IETF Stream drafts tend to apply across all four document streams, and publication-related tools tend to focus on the IETF as the primary audience for their use. It is difficult for people to see how, or even why, there is a distinction between the Series and the IETF.¶
We are in the midst of that question now more than ever. What is the future of the Series? If people cannot tell where the IETF ends and the Series starts, should we consider this an artificial distinction and declare them to be the same entity?¶
Ultimately, this will be something the community decides, and conversations are underway to consider the ramifications of possible changes.¶
As the Internet evolves, expectations and possibilities evolve, too. Over the next fifty years, the Series will continue to demonstrate a balance between the need to stay true to the original mission of publication and preservation, while also staying relevant to the needs of the authors and consumers of RFCs. The tension in balancing those needs rests on the RFC Editor and the community to resolve. We will not run short of challenges.¶
This document has no IANA actions.¶
This document has no security considerations.¶
Many thanks to John Klensin for his feedback and insights on the history of the Series, as someone who directly engaged and influenced many of the key individuals involved in developing the RFC Series.¶
Additional thanks to members of the RFC Series Advisory group and the Independent Submissions Editorial Board, in particular, Scott Bradner, Brian Carpenter, and Adrian Farrel, for their early reviews and input into the sequence of key moments in the history of the Series.¶
Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownlee, and Sandy Ginoza for their perspectives on the Series and their ongoing support.¶


I have 10 acres of well
nurtured kales.
Site visit are welcomed
Pay half amount upfront
to reserve/book.
I have 10 acres of well
nurtured cabbage.
Site visit are welcomed
Pay half amount upfront
to reserve/book.
I have 10 acres of well
nurtured carrots.
Site visit are welcomed
Pay half amount upfront
to reserve/book.
I have 10 acres of well
nurtured corriander.
Site visit are welcomed
Pay half amount upfront
to reserve/book.
I have 10 acres of well
nurtured onions.
Site visit are welcomed
Pay half amount upfront
to reserve/book.
I have 10 acres of well
nurtured bellpepper.
Site visit are welcomed
Pay half amount upfront
to reserve/book.


Hello World
My name is Simarjot Sidhu.
Welcome to my personal GitHub Page.
Visit my about page here!
Visit my projects page here!
Visit my GitHub here!


A farmer has a fox, a goose and a bag of corn (or beans in some versions) and needs to cross a river;
- The farmer can only take one item across the river at a time.
- The fox and the goose must not be left together unattended.
- The goose and the corn must not be left together unattended.
how does the farmer cross the river?
We appear to have four items (the farmer, the fox, the goose and the corn)
each of which can be in two states (on the near side of the river or on the far side of the river).
So we could use binary notation, starting at
0000
and finishing at
1111.
But do we really need to model the farmer?
We are only really interested in the
transitions between the states of the fox, the goose and the corn.
So this puzzle is similar to the
light-switch puzzle.
So let's rewrite the rules as a light-switch puzzle, where the switches are labelled
“fox”,
“goose” and
“corn”.
- You can only flick one switch at a time (either on or off)
- You can’t switch the fox on leaving goose and corn off.

- If the fox and goose are on, you can’t also turn the corn on.
- If the corn and goose are on, you can’t also turn the fox on.
The first 3 rules obviously obey the rules of the fox-goose-corn puzzle.
You can only take one item at a time and you can’t leave the goose and corn or fox and goose together on the near
side of the river as you take the other item across.
But what about rules 4 and 5?
Well, if the fox and goose are already across the river (they are
“on”),
the only way that the farmer can bring the corn across
(to switch it “on”)
is to be on the near side of the river to bring it across which would leave the fox and goose unattended on the far side.
So rule 4,
does obey the rules of the fox-goose-corn puzzle.
And, similarly, so does rule 5.
So we have re-written the fox-goose-corn puzzle as a light-switch puzzle.
And since we previously rewrote that puzzle as the ant-on-the-box
puzzle, then we can rewrite this puzzle in the same way too.


About
This project is geared towards young researchers such as undergraduates motivated to pursue graduate school. Undergraduate research experience is a major factor in graduate admissions. However, as a beginner, it is extremely challenging for an undergrad to identify the broad research topics and the fastest growing areas in any field he/she is interested in. Moreover, simply going through publication databases isn't a viable solution: every year thousands of papers are published in every research area in physics!
This project attempts to answer some of these problems. I have identified and compared the buzzwords of two different years which gives us an indication of the rising trends in physics. Using topic modelling, I have identified broad research topics as well as sub-topics contained in them. An interested reader can not only get a clear view of the research landscape in any broad are in physics but also find out some of the specific questions that belong to any field.
Visit my GitHub repository to understand the machine learning techniques implemented in this project.
Exploratory Data Analysis
Rising Trends in Physics
Using the arXiv database for physics, I have compared the buzzwords in all areas of physics between two different years, 2010 (on the left) and 2020 (on the right). To create this comparison, I analyzed ~7400 publication titles from 2010 and ~17,000 from 2020. We can see some emerging trends such as 'neural networks' and 'machine learning' as well as some topics that have stayed both stable and prolific over the years such as 'optics'. This is an indication that machine learning is gaining popularity in physics and is a very useful skill to possess. Notice that COVID was also talked about frequently by physicists in 2020. 'Neural Network' can be seen as an emerging technique in 2020, unheard of ten years ago.
In 2010, the top 10 most used words were:
'dynamic',
'quantum',
'network',
'optical',
'plasma',
'theory',
'state',
'simulation',
'electron',
'particle'
In 2020, the top 10 most used words are:
'dynamic',
'quantum',
'network',
'optical',
'simulation',
'flow',
'COVID',
'state',
'Modeling',
'Neural Network'
Most popular fields in Physics
A bar chart provided below compares the most active fields within physics between 2010 and 2020. The numbers on the X-axis are the publication count. Comparing the 2010 and 2020 research trends, we see that the field of 'Optics' stayed the most active in a decade. In contrast, 'Applied Physics' has become more active recently whereas 'Physics and Society' has become less popular since 2010.
Also notice that even in a given field, for example Optics, the total number of publications has grown almost by a factor of three. Physics as an entire discipline is growing with every decade, more papers being published every year.
Rising trends: a closer look
We can also look at the change in popularity of some key words/phrases over the years. Plotted below are the frequency vs. year (on the left in blue) and percentage increase from the previous year vs. year (on the right in red) of two phrases, such as 'Neural Network' (top panel) and 'Black Hole' (bottom panel) for example. Neural networks has seen a steady increase in popularity over the years, especially in the year 2017. Black holes, on the other hand, gained popularity between 2015 and 2017 which could be due to the discovery of binary black hole mergers by LIGO in 2015.
Concluding Remarks
So far we looked at some Exploratory Data Analysis results.- We identified some new techniques such as 'Neural Networks' that are gaining traction in physics. For a motivated undergrad, having some experience in such techniques could play a vital role in graduate admissions decisions.
- One could also analyze the change in popularity of certain terms over the years. For instance, 'Black Holes' suddenly started to trend in 2015. Identifying such suddenly rising trends could point to some groundbreaking discoveries/publications worth being aware about.
- Finally, one could examine which are the most stable fields over the years, perhaps indicating that the field is vibrant and full of mysteries.
Topic modeling
For topic identification, I implemented unsupervised machine learning algorithms such as k-means clustering and the Latent Dirichlet Allocation or LDA. In k-means clustering, each document is viewed as a multi-dimensional vector of the matrix. Two documents are similar to one another if their corresponding vectors are close to one another or, in other words, if the difference of their vectors is small in length. We can use this common clustering method to group our documents together to find topics of research in Astophysics (astro-ph).
In LDA, each word in a document is assigned a topic. Initially, this assignment is done randomly. To improve upon the assignment of topics to each word, we look at the probability of a word, w, belonging to a particular topic, t. This is calculated by making a subsample of all documents that are classified as a particular topic t and the number of documents in that subsample that contains the word w. The LDA then goes through each document in the corpus and calculates the probability that a topic t is contained in a document d. These two probabilities assign a new probability to every word in the document of belonging to a topic. Repeating this process many times gives us an equilibrium value of the probabilities associated with each word and document.
Let us first begin with the simplest clustering algorithm, the k-means. After cleaning up the data, the k-means clusters can be labelled as:
| k-means clustering |
|---|
| Stellar & Planetary physics |
| Solar physics |
| Gravitational waves and Neutron stars |
| Gravitational waves and Black holes |
| Dark Matter |
Visualizations
Let's look at a few visualizations from the clustering algorithms to get more insights from the data.
Word Cloud
First let's take a look at the most frequent words in a couple of the clusters through wordclouds. This will help us label the 5 clusters.
The two wordclouds above belong to the clusters from the k-means algorithm. Similar wordclouds can be made for all the other clusters for both algorithms. More details have been provided in the Python notebook in GitHub.
Cluster size
We see that in the k-means approach, Stellar & Planetary physics is the largest cluster. This seems to be consistent with my personal experience of going through the arXiv database in the past few years.
Word Frequencies
Next, we can look at the number of occurences in each cluster of some of the most frequent words in the corpus. This visualization could suggest some additional stop words that we might want to add (and then reprocess the resulting new bag of words matrix) to make our clustering better.
Number of Clusters
To verify that 5 is a reasonable assumption of the number of clusters, let's look at the inertia plot. The inertia value on the y-axis is related to the average distance between the cluster center and the data points. The lower the inertia the better the number of clusters.
One can notice that the inertia marginally tapers at 4. The improvements in inertia become a little gradual beyond that value. Therfore, 5 is a good choice for the number of clusters.
Low-dimensional representation
We can use PCA to project the high-dimensional vector representation of our text corpus into a lower-dimensional space. This could give us an indication of the separation or overlapping between the clusters.
We see that some clusters, eg. Cluster 3 (brown) and 4 (gray) are relatively well-defined: most of the documents belonging to these clusters lie along one axis. There is some mixing in the other clusters, e.g. Clusters 0 (blue) and 2 (green), possibly because of the limitation of the projection down into a two-dimensional space. Alternatively, this could also mean that there is overlap between the clusters. There is reason that this might be true because neutron stars are the end state of many stars. Therefore Cluster 0 (Stellar & Planetary physics) and Cluster 2 (Gravitational Waves and Neutron stars) are related.
Latent Dirichlet Allocation or LDA
One way to improve on our current clustering method is to predict the probability with which a document is assigned a cluster. LDA is one such algorithm which does that. After pre-processing the data and implementing the LDA algorithm from the gensim
library, I arrived at the following topics:
| LDA topics |
|---|
| Observations from Hubble Space Telescope |
| Galactic center |
| Dark Matter & Baryons |
| Stellar Physics |
| Galaxy surveys & galactic physics |
| Gravitational wave sources |
| Cosmic Microwave Background or CMB |
We will see in a moment why 7 is the appropriate number of clusters for LDA.
Cluster Size
For the LDA, the cluster/topic sizes were:Word Frequencies
Number of Topics: Coherence Score
The coherence score captures the semantic information of the document by looking at the co-occurence of pairs of words in the document. It can take a value between -1 (worst) and 1 (best). I calculated the coherence scores for different number of topics. I then plotted the percentage improvement in the coherence score with increasing number of topics:
The biggest improvement in coherence score, 15%, occurs when the number of topics increases to four. However, from my experience, it seems like a low number. The next biggest improvement occurs when there are 7 topics. Therefore, the initial assumption of 7 topics turns out to be reasonable.
Example
Finally, let us take a look at an abstract/document from the database/corpus and compare the topics it was assigned to by the two different methods.
We present an upgrade of the OGLE Collection of RR Lyrae stars in the Galactic bulge and disk. The size of our sample has been doubled and reached 78 350 RR Lyr variables, of which 56 508 are fundamental-mode pulsators (RRab stars), 21 321 pulsate solely in the first-overtone (RRc stars), 458 are classical double-mode pulsators (RRd stars), and 63 are anomalous RRd variables (including five triple-mode pulsators). For all the newly identified RR Lyr stars, we publish time-series photometry obtained during the OGLE Galaxy Variability Survey. We present the spatial distribution of RR Lyr stars on the sky, provide a list of globular clusters hosting RR Lyr variables, and discuss the Petersen diagram for multimode pulsators. We find new RRd stars belonging to a compact group in the Petersen diagram (with period ratios P_1O/P_F = 0.74 and fundamental-mode periods P_F = 0.44 d) and we show that their spatial distribution is roughly spherically symmetrical around the Milky Way center.
The k-means clustering method assigns the document to the Stellar & Planetary physics cluster. This is a fair result given that the abstract contains the term 'stars'.
The one shortcoming of the k-means clustering method is that it strictly categorizes the documents. LDA is advantageous since it gives us the probabilities of the topics for each document. For the above abstract, the 2 top-most topics are Galactic center with probability of 0.75 and Stellar Physics with probability of 0.08.
Concluding Remarks
- We saw that in a broad field such as Astrophysics, there are some distinct sub topics for example: stellar and planetary physics, gravitational waves, dark matter and cosmic microwave background.
- For the k-means clustering, 5 is an appropriate number of clusters. For LDA, which takes into account the semantic structure of the text, the appropriate number of topics is 7.
- We can also look at the multidisciplinary nature of the articles through LDA.


{% extends "base.html" %} {% block title %}Logged out{% endblock %} {% block content_header %}Logged out{% endblock %} {% block main_content %}
You've been logged out.
{% endblock %} {% block sidebar %}Thanks for stopping by; when you come back, don't forget to log in again.
{% endblock %}


Thanks to those who have got me this far with my quest to monitor my PV and home electricity status using emonTx v3 with a R Pi/RFM69. I'm almost there but the last hurdle of getting my data to emoncms.org eludes me.
This is a copy of the log
2016-01-26 17:51:27,652 INFO emonCMS sending: http://localhost/emoncms/input /bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y& data=[[1453830687.53,8,3,540,0,0,24232,3000,3000,3000,3000,3000,3000,1,0,- 38]]&sentat=1453830687 2016-01-26 17:51:27,719 DEBUG emonCMS acknowledged receipt with 'ok' from http://localhost/emoncms 2016-01-26 17:51:37,337 DEBUG 983 NEW FRAME :<PHONE_NUMBER>.34 OK 8 2 0 29 2 0 0 0 0 93 94 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-41) 2016-01-26 17:51:37,341 DEBUG 983 Timestamp :<PHONE_NUMBER>.34 2016-01-26 17:51:37,342 DEBUG 983 Node : 8 2016-01-26 17:51:37,343 DEBUG 983 Values : [2, 541, 0, 0, 24157, 3000, 3000, 3000, 3000, 3000, 3000, 1, 0] 2016-01-26 17:51:37,345 DEBUG 983 RSSI : -41 2016-01-26 17:51:37,350 DEBUG 983 Append to 'emonCMS' buffer => time:<PHONE_NUMBER>.34, data: [8, 2, 541, 0, 0, 24157, 3000, 3000, 3000, 3000, 3000, 3000, 1, 0, -41], ref: 983
and this is my emon.conf file (with the API keys blanked
# SPECIMEN emonHub configuration file # Note that when installed from apt, a new config file is written # by the debian/postinst script, so changing this file will do # nothing in and of itself. # Each Interfacer and each Reporter has # - a [[name]]: a unique string # - a type: the name of the class it instantiates # - a set of init_settings (depends on the type) # - a set of runtimesettings (depends on the type) # Both init_settings and runtimesettings sections must be defined, # even if empty. Init settings are used at initialization, # and runtime settings are refreshed on a regular basis. # All lines beginning with a '#' are comments and can be safely removed. ####################################################################### ####################### emonHub settings ####################### ####################################################################### [hub] # loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL # see here : http://docs.python.org/2/library/logging.html loglevel = DEBUG ####################################################################### ####################### Reporters ####################### ####################################################################### [reporters] # This reporter sends data to emonCMS [[emonCMS]] Type = EmonHubEmoncmsReporter [[[init_settings]]] [[[runtimesettings]]] url = http://localhost/emoncms #(defaults to emoncms.org) apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [[emoncmsorg]] Type = EmonHubEmoncmsHTTPInterfacer [[[init_settings]]] [[[runtimesettings]]] pubchannels = ToRFM12, subchannels = ToEmonCMS, url = http://emoncms.org [1] apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx senddata = 1 sendstatus = 1 ####################################################################### ####################### Interfacers ####################### ####################################################################### [interfacers] # This interfacer manages the RFM2Pi module [[RFM2Pi]] Type = EmonHubJeeInterfacer [[[init_settings]]] com_port = /dev/ttyAMA0 [[[runtimesettings]]] group = 210 frequency = 433 baseid = 15 ####################################################################### ####################### Nodes ####################### ####################################################################### [nodes] # List of nodes by node ID # 'datacode' is default for node and 'datacodes' are per value data codes. # if both are present 'datacode' is ignored in favour of 'datacodes' [[10]] Please will someone look at my emonhub.conf file and see if any errors can be spotted.
Edit - wrapped long lines - Moderator, BT
Re: emonhub.conf not reporting to emoncms.org?
You have filled in your Read & Write APIkey in the real file, haven't you?
And what is the [1] doing on the end of the URL?
Re: emonhub.conf not reporting to emoncms.org?
Hi Rob
Thank you, yes I have put in the API keys. I know not how the [1] at the end of the URL was copied in, however, I have removed it and it has not made any difference to the log report.
Could it be anything to do with nodes and datacodes? I have played around with a bunch of these to varying effect.
Changing the [[10]] to [[8]] (as one would expect to be correct as the log refers to node 8, causes nothing to be updated on my localhost/emoncms.
Including
datacodes = L, h, h, h, h, l, l, l, l
as recommended by the support documentation, produces in the log a WARNING that these codes are not sufficient for the 26 bites of information being supplied.
I have found better results excluding the data codes. At least I get local reporting then.
Thanks for your interest
Rob
Re: emonhub.conf not reporting to emoncms.org?
To solve the datacodes question, you need to go back to your emonTx and determine what its NodeID is and which sketch it is running, from which we can put together the requisite strings. If there is any inconsistency, the packet gets rejected by emonhub, and won't get sent to either emoncms.org or to your local emoncms. By excluding "datacodes = ", you actually used the default "datacode = h", meaning the data stream was interpreted as all signed integers.
http://openenergymonitor.org/emon/node/11950#comment-37981 and Paul's follow-up below it might help a little.
Re: emonhub.conf not reporting to emoncms.org?
The main issue here is the "EmonHubEmoncmsHTTPInterfacer" in the [reporters] section. Change
[[emoncmsorg]]
Type = EmonHubEmoncmsHTTPInterfacer
[[[init_settings]]]
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
url = http://emoncms.org
apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
senddata = 1
sendstatus = 1
To
[[emoncmsorg]]
Type = EmonHubEmoncmsReporter
[[[init_settings]]]
[[[runtimesettings]]]
url = http://emoncms.org
apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The "emon-pi" variant doesn't have "reporters" and the original version of emonHub doesn't have "EmonHubEmoncmsHTTPInterfacers".
Assuming you are using v1.2 (original) emonhub and a "stock" emontx v3 you shouldn't need to define the node, you can if you wish but it shouldn't be mandatory as it's payload only has signed integers so no other datatypes force the need for defining the node. Plus you are not using the nodes module and the input module doesn't make defining nodes mandatory either, so you should be good with an empty [nodes] section.
Paul
Re: emonhub.conf not reporting to emoncms.org?
Hi Paul,
This is brilliant. It works! Thank you so much
Rob


Data Science Boot Camp
1
Welcome
I Core theory
2
Principles of data science
2.1
What is data science?
2.2
What is the data life cycle?
2.3
What is a pipeline?
2.4
Data science ‘in the wild’
2.5
The reproducibility crisis
3
Visualizing data
3.1
Bad examples
3.2
Good exaples
3.3
Edward Tufte
3.4
Grammar of graphics
3.5
Design principles
3.6
Plots & power
4
Writing about data
5
Data ethics
II Getting started
6
Setting up RStudio
7
Running R code:
7.1
Basic math
7.2
Operators
8
RStudio workflows
8.1
Tour of RStudio
8.2
Scripts
8.3
Typical workflows
9
Objects in R
9.1
Variables
9.2
Vectors
10
Calling functions
11
Base plots
12
Packages
13
Basics of ggplot
III Working with data in R
14
Importing data
14.1
Working directories
14.2
Reading in data
15
Dataframes
15.1
Exploration
15.2
Summarization
16
Data wrangling
16.1
Data transformation
16.1.1
Filtering
16.1.2
Grouping
16.1.3
Joining
16.2
The tidyverse and tibbles
16.3
Transformation with dplyr
16.3.1
Filtering
16.3.2
Grouping
16.3.3
Mutating
IV Exploring & analyzing data
17
Exploratory Data Analysis
17.1
Exploring distributions
17.2
Variable types & statistics
17.3
Descriptive statistics
18
Significance statistics
18.1
Thinking about significance
18.2
Comparison tests
18.3
Correlation tests
19
Displaying data
19.1
Tables
19.2
Base plots
19.3
ggplot
V Creating your own dataset
19.4
Managing project files
19.5
Formatting your own data
19.6
Reading Excel files
19.7
Reading GoogleSheets
19.8
Reading online data
VI Your R tool bag
20
Joining datasets
21
For loops
22
Writing functions
23
Working with text
24
Working with dates & times
25
Working with factors
26
Cleaning messy data
27
Matrices & lists
28
Pipes
29
Exporting data & plots
VII Interactive dashboards
30
Intro to Shiny apps
31
Shiny dashboards
32
Data entry apps
VIII Documenting your work
33
R Markdown
34
Reproducible research
35
Automated reporting
36
Formatting standards
36.1
Tables
36.2
Figures
36.3
Captions
IX Databases
37
Introduction
37.1
What
37.2
Why
37.3
When
37.4
When not
X Databases
38
Platforms:
38.1
PostgreSQL
38.2
mySQL
38.3
SQLite
XI Databases
39
Alternatives:
39.1
NoSQL
XII Databases
40
Practices
XIII Version control and teamwork
41
What is version control?
42
What is Git?
42.1
Repositories
42.2
Github
43
Standard git operations
44
A git workflow
45
Other git platforms
XIV Documenting your work
46
R Markdown
47
Reproducible research
48
Automated reporting
49
Formatting standards
49.1
Tables
49.2
Figures
49.3
Captions
XV Version control and teamwork
50
What is version control?
51
What is Git?
51.1
Repositories
51.2
Github
52
Standard git operations
53
A git workflow
54
Other git platforms
XVI Advanced skills
55
Mapping
56
Geographic computing & GIS
57
Statistical modeling
58
Apply family
59
Iterative statistics
60
Iterative simulations
XVII Writing about data
61
Types of writing
61.1
Grant proposals
61.2
Reports and publications
61.3
Fundraising
61.4
Press releases
62
Elements of style
63
Sections of a report
63.1
Abstract
63.2
Introduction
63.3
Methods
63.4
Results
63.5
Discussion
63.6
Other elements
63.6.1
Acknowledgments
63.6.2
Literature Cited
63.6.3
Tables
63.6.4
Figures
63.6.5
Supplementary Materials
XVIII Creating websites
XIX Advanced skills
64
Mapping
65
Geographic computing & GIS
66
Statistical modeling
67
Apply family
68
Iterative statistics
69
Iterative simulations
References
Databrew LLC
Data Science Boot Camp
Module 68
Iterative statistics


Hello, I’m Tanvir Ovi . I am a student . The name of my varsity is " UNIVERSITY OF CHITTAGONG ". Now I’m doing my B.S.C ENGINEERING in Department of " ELECTRICAL & ELECTRONIC ENGINEERING "
Hello, I’m front end web developer. Though I’m new in this section but I will try my best to provide a good service. I ensure my clients' desired service. I have a solid experience on ▣ Error Fix ▣ Performance Optimization ▣ Responsive Web Design ▣ HTML5 & Bootstrap ▣ CSS3 ▣ Logo Design. My aim is to give my clients exactly what they need and guide them all through the procedure. My client's Success is my Success. If I remain in offline, just drop your message. I shall give you a reply within a few moments .
View ResumeThis is a small project. This project is super responsive. If you want to seach any robot you can serch it from seacrh bar. I devloped it by using "React".
Sometime user does not like the background color. In this project user can generate unique background . Now he can choose his desirable background by clicking the input option.
If I remain offline, don't hesitate to knock me!
Call to Action


Terrychat Login
Please Sign In
Username
Password
Forgot password?
Remember Me
Sign in
Need an Account?
Sign Up
Terrychat


6.6. Runtime Configuration¶
GeoMesa uses system properties for various runtime configuration options. As a convenience, properties
can be specified in an XML file instead of the command line. When run, GeoMesa will load
the file geomesa-site.xml
from the classpath (if available), and use any properties configured there.
To configure a GeoMesa binary distribution, place geomesa-site.xml
in the conf
folder.
For GeoServer, place the file under geoserver/WEB-INF/classes
. For other environments,
ensure the file is available at the root level of the classpath.
Each tools distribution contains a template file with the default settings at
conf/geomesa-site.xml.template
. Do not modify this file directly as it is never read;
instead copy the desired configurations into geomesa-site.xml
.
By default, system properties set through command line parameters will take precedence over the
configuration file. If you wish a configuration item to always take precedence, even over command
line parameters, change the <final>
tag to true.
Configuration properties with empty values will not be applied, you can change this by marking a property as final.
6.6.1. Common Properties¶
These properties apply to all GeoMesa implementations. Additional properties for different back-end databases can be found in the chapters for each one.
<IP_ADDRESS>. geomesa.audit.provider.impl¶
This property specifies the fully-qualified class name of an audit provider implementation to use. For more information, see Query Auditing.
<IP_ADDRESS>. geomesa.convert.config.urls¶
This property allows for adding GeoMesa converter configurations to the environment. It can be set to a comma-separated list of arbitrary URLs. For more information on converters, see GeoMesa Convert.
<IP_ADDRESS>. geomesa.convert.scripts.path¶
This property allows for adding files to the classpath. It should be set to a colon-separated list of file paths. This is useful for getting scripts onto the classpath for use by map-reduce ingest jobs.
<IP_ADDRESS>. geomesa.distributed.version.check¶
This property can be used to check for version mismatches in the distributed classpath. When enabled, GeoMesa will throw an exception if it detects a major version discrepancy between the local classpath and the distributed classpath (e.g. HBase region servers or Accumulo tablet servers), as this will generally cause queries to fail. If not enabled, then classpath errors will not be detected proactively, and will likely result in runtime exceptions.
<IP_ADDRESS>. geomesa.feature.id-generator¶
This property controls the default implementation used for generating IDs for simple features,
if the USE_PROVIDED_FIDS
or PROVIDED_FID
hint is not set in the feature. It should be set to
the fully-qualified class name for a class implementing org.locationtech.geomesa.utils.uuid.FeatureIdGenerator
.
GeoMesa includes an implementing class org.locationtech.geomesa.utils.uuid.Z3FeatureIdGenerator
, which creates
a unique feature ID partially based on the default time and geometry for the feature. This class is used by
default if nothing else is specified, and should work well for most situations.
<IP_ADDRESS>. geomesa.filter.hash.threshold¶
Evaluating a filter of the form name = 'john' OR name = 'jane' OR name = 'doe'
can be slow if the number
of clauses is high. GeoMesa will optimize such filters by turning them into a hash lookup instead of a sequential
comparison. This property controls the threshold for switching to a hash lookup. By default, the threshold is 5
.
Note that for datastores with distributed filtering (e.g. HBase and Accumulo), this property needs to be set on the distributed processing nodes.
<IP_ADDRESS>. geomesa.force.count¶
This property controls how GeoMesa calculates the size of a result set (e.g. FeatureSource.getCount
).
By default, GeoMesa will estimate the size of a result set using statistics. This will provide a
rough estimate very quickly. Some applications rely on knowing the exact size of a result set up
front, so estimates will cause problems. To force GeoMesa to calculate the exact size of a result
set, you may set this property to true
. You may also override this behavior on a per-query basis
by using the query hint org.locationtech.geomesa.accumulo.index.QueryHints.EXACT_COUNT
.
<IP_ADDRESS>. geomesa.metadata.expiry¶
This property controls how often simple feature type metadata is read from the underlying data store.
Calls to updateSchema
on a data store will not show up in other instances until the metadata
cache has expired. The expiry is specified as a duration, e.g. 10 minutes
or 1 hour
.
<IP_ADDRESS>. geomesa.partition.scan.parallel¶
This property controls how scans against multiple, partitioned tables are executed. By default scans will be
executed sequentially. If set to true
, they will be executed in parallel. See Configuring Partitioned Indices
for details on partitioning.
<IP_ADDRESS>. geomesa.query.cost.type¶
This property controls how GeoMesa performs query planning. By default, GeoMesa will perform cost-based
query planning using data statistics to determine the best index for a given query. As a fallback option,
this property may be set to index
to use heuristic-based query planning. This may also be overridden on a
per-query basis using the query hint org.locationtech.geomesa.accumulo.index.QueryHints.COST_EVALUATION_KEY
set to either org.locationtech.geomesa.accumulo.index.QueryPlanner.CostEvaluation.Stats
or org.locationtech.geomesa.accumulo.index.QueryPlanner.CostEvaluation.Index
. See Query Planning
for more details on query planning strategies.
<IP_ADDRESS>. geomesa.query.decomposition.bits¶
In addition to geomesa.query.decomposition.multiplier
, below, geomesa.query.decomposition.bits
sets a
lower threshold on the size of the envelopes. It must be between 1 and 63, inclusive. See the Wikipedia article
on GeoHashes for the approximate spatial extent
of a given number of bits.
<IP_ADDRESS>. geomesa.query.decomposition.multiplier¶
GeoMesa creates scan ranges based on the spatial predicates in a query. For complex spatial predicates, GeoMesa will decompose the geometry into smaller, rectangular envelopes, which avoids scanning over rows which don’t intersect the geometry. This behavior can be controlled through two properties.
geomesa.query.decomposition.multiplier
controls the maximum number of envelopes that a geometry will be
decomposed into. If set below 2, no decomposition will be performed and instead the geometry envelope will be used.
Also see geomesa.query.decomposition.bits
, above.
<IP_ADDRESS>. geomesa.query.timeout¶
This property can be used to prevent long-running queries from overloading the system. When set,
queries will be closed after the timeout, even if not all results have been returned yet. The
timeout is specified as a duration, e.g. 1 minute
or 30 seconds
.
<IP_ADDRESS>. geomesa.scan.block-full-table¶
This property will prevent full-table scans from executing. A full-table scan is any query that can’t be
constrained down using a search index, and thus requires scanning the entire data set. With large data sets,
such a scan can last a long time and be resource intensive. The property is specified as a Boolean, i.e.
true
or false
.
For more granularity, it is also possible to specify the full-table scan behavior for individual schemas
(SimpleFeatureTypes
). Use geomesa.scan.<type-name>.block-full-table
, where <type-name>
is
replaced with the schema name (e.g. “gdelt”). Properties set for an individual schema will take precedence
over the globally-defined behavior.
<IP_ADDRESS>. geomesa.scan.ranges.target¶
This property provides a rough upper-limit for the number of row ranges that will be scanned for a single query. It is specified as a number. In general, more ranges will result in fewer false-positive rows being scanned, which will speed up most queries. However, too many ranges can take a long time to generate, and overwhelm clients, causing slowdowns. The optimal value depends on the environment.
<IP_ADDRESS>. geomesa.sft.config.urls¶
This property allows for adding GeoMesa simple feature type configurations to the environment. It can be set to a comma-separated list of arbitrary URLs. For more information on defining types, see Defining Simple Feature Types.
<IP_ADDRESS>. geomesa.stats.generate¶
This property controls whether GeoMesa will generate statistics during ingestion. It is specified as a Boolean,
true
or false
. This property will be used if a data store is not explicitly configured using the
geomesa.stats.enable
data store parameter.
<IP_ADDRESS>. geomesa.strategy.decider¶
This property allows for overriding strategy selection during query planning. It should specify the
full class name for a class implementing org.locationtech.geomesa.index.planning.StrategyDecider
.
The class must have a no-arg constructor.
By default GeoMesa will use cost-based query planning, which should work well for most situations. See Query Planning for more details on query planning strategies.


collections
Data structs
Basically you don't need to re-implement code for concrete types
reuse code: no boilerplate
increased complexity in the type system and run-time
intended for writing server programs that would be easy to maintain over time.
scalability
readability
concurrency
Polymorphic programming not a goal,so it was left out for simplicity.
func Stringify(type T)(s []T) (ret []string) {
for _, v := range s {
ret = append(ret, v.String()) // INVALID
}
return ret
}
contract stringer(x T) {
var s string = x.String()
}
func Stringify(type T stringer)(s []T) (ret []string) {
for _, v := range s {
ret = append(ret, v.String()) // now valid
}
return ret
}


{% comment %} Included in occurrence_list.html and anywhere else it is needed Be sure to load datatables css in the header of any template calling this. {% endcomment %}


public final class HcsIdentityNetwork
extends java.lang.Object
| Modifier and Type | Method and Description |
|---|---|
HcsDidTransaction |
createDidTransaction(DidMethodOperation operation)
Instantiates a
HcsDidTransaction to perform the specified operation on the DID document. |
HcsDidTransaction |
createDidTransaction(MessageEnvelope<HcsDidMessage> message)
Instantiates a
HcsDidTransaction to perform the specified operation on the DID document. |
HcsVcTransaction |
createVcTransaction(HcsVcOperation operation,
java.lang.String credentialHash,
com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey signerPublicKey)
Instantiates a
HcsVcTransaction to perform the specified operation on the VC document. |
HcsVcTransaction |
createVcTransaction(MessageEnvelope<HcsVcMessage> message,
com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey signerPublicKey)
Instantiates a
HcsVcTransaction to perform the specified operation on the VC document status. |
static HcsIdentityNetwork |
fromAddressBook(HederaNetwork network,
AddressBook addressBook)
Instantiates existing identity network from a provided address book.
|
static HcsIdentityNetwork |
fromAddressBookFile(com.hedera.hashgraph.sdk.Client client,
HederaNetwork network,
com.hedera.hashgraph.sdk.file.FileId addressBookFileId,
com.hedera.hashgraph.sdk.Hbar maxQueryPayment)
Instantiates existing identity network using an address book file read from Hedera File Service.
|
static HcsIdentityNetwork |
fromHcsDid(com.hedera.hashgraph.sdk.Client client,
HcsDid hcsDid,
com.hedera.hashgraph.sdk.Hbar maxQueryPayment)
Instantiates existing identity network using a DID generated for this network.
|
HcsDid |
generateDid(boolean withTid)
Generates a new DID and it's root key.
|
HcsDid |
generateDid(com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey publicKey,
boolean withTid)
Generates a new DID from the given public DID root key.
|
HcsDid |
generateDid(java.security.SecureRandom secureRandom,
boolean withTid)
Generates a new DID and it's root key using a cryptographically strong random number generator.
|
AddressBook |
getAddressBook()
Returns the address book of this identity network.
|
HcsDidResolver |
getDidResolver()
Returns a DID resolver for this network.
|
com.hedera.hashgraph.sdk.consensus.TopicId |
getDidTopicId()
Returns DID topic ID for this network.
|
HcsDidTopicListener |
getDidTopicListener()
Returns a DID topic listener for this network.
|
HederaNetwork |
getNetwork()
Returns the Hedera network on which this identity network runs.
|
HcsVcStatusResolver |
getVcStatusResolver()
Returns a VC status resolver for this network.
|
HcsVcStatusResolver |
getVcStatusResolver(java.util.function.Function<java.lang.String,java.util.Collection<com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey>> publicKeysProvider)
Returns a VC status resolver for this network.
|
com.hedera.hashgraph.sdk.consensus.TopicId |
getVcTopicId()
Returns Verifiable Credentials topic ID for this network.
|
HcsVcTopicListener |
getVcTopicListener()
Returns a VC topic listener for this network.
|
HcsVcTopicListener |
getVcTopicListener(java.util.function.Function<java.lang.String,java.util.Collection<com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey>> publicKeysProvider)
Returns a VC topic listener for this network.
|
public static HcsIdentityNetwork fromAddressBook(HederaNetwork network, AddressBook addressBook)
network
- The Hedera network.addressBook
- The AddressBook
of the identity network.public static HcsIdentityNetwork fromAddressBookFile(com.hedera.hashgraph.sdk.Client client, HederaNetwork network, com.hedera.hashgraph.sdk.file.FileId addressBookFileId, com.hedera.hashgraph.sdk.Hbar maxQueryPayment) throws com.hedera.hashgraph.sdk.HederaNetworkException, com.hedera.hashgraph.sdk.HederaStatusException
client
- The Hedera network client.network
- The Hedera network.addressBookFileId
- The FileID of AddressBook
file stored on Hedera File Service.maxQueryPayment
- Maximum HBAR payment for querying the address book file content.com.hedera.hashgraph.sdk.HederaStatusException
- In case querying Hedera File Service fails.com.hedera.hashgraph.sdk.HederaNetworkException
- In case of querying Hedera File Service fails due to transport calls.public static HcsIdentityNetwork fromHcsDid(com.hedera.hashgraph.sdk.Client client, HcsDid hcsDid, com.hedera.hashgraph.sdk.Hbar maxQueryPayment) throws com.hedera.hashgraph.sdk.HederaNetworkException, com.hedera.hashgraph.sdk.HederaStatusException
client
- The Hedera network client.hcsDid
- The Hedera HCS DID.maxQueryPayment
- Maximum HBAR payment for querying the address book file content.com.hedera.hashgraph.sdk.HederaStatusException
- In case querying Hedera File Service fails.com.hedera.hashgraph.sdk.HederaNetworkException
- In case of querying Hedera File Service fails due to transport calls.public HcsDidTransaction createDidTransaction(DidMethodOperation operation)
HcsDidTransaction
to perform the specified operation on the DID document.operation
- The operation to be performed on a DID document.HcsDidTransaction
instance.public HcsDidTransaction createDidTransaction(MessageEnvelope<HcsDidMessage> message)
HcsDidTransaction
to perform the specified operation on the DID document.message
- The DID topic message ready to for sending.HcsDidTransaction
instance.public HcsVcTransaction createVcTransaction(HcsVcOperation operation, java.lang.String credentialHash, com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey signerPublicKey)
HcsVcTransaction
to perform the specified operation on the VC document.operation
- The type of operation.credentialHash
- Credential hash.signerPublicKey
- Public key of the signer (issuer).public HcsVcTransaction createVcTransaction(MessageEnvelope<HcsVcMessage> message, com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey signerPublicKey)
HcsVcTransaction
to perform the specified operation on the VC document status.message
- The VC topic message ready to for sending.signerPublicKey
- Public key of the signer (usually issuer).HcsVcTransaction
instance.public AddressBook getAddressBook()
public HederaNetwork getNetwork()
public HcsDid generateDid(boolean withTid)
withTid
- Indicates if DID topic ID should be added to the DID as tid parameter.HcsDid
with it's private DID root key.public HcsDid generateDid(com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey publicKey, boolean withTid)
publicKey
- A DID root key.withTid
- Indicates if DID topic ID should be added to the DID as tid parameter.public HcsDid generateDid(java.security.SecureRandom secureRandom, boolean withTid)
secureRandom
- Cryptographically strong random number generator.withTid
- Indicates if DID topic ID should be added to the DID as tid parameter.HcsDid
with it's private DID root key.public HcsDidResolver getDidResolver()
public com.hedera.hashgraph.sdk.consensus.TopicId getDidTopicId()
public HcsDidTopicListener getDidTopicListener()
public com.hedera.hashgraph.sdk.consensus.TopicId getVcTopicId()
public HcsVcStatusResolver getVcStatusResolver()
public HcsVcStatusResolver getVcStatusResolver(java.util.function.Function<java.lang.String,java.util.Collection<com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey>> publicKeysProvider)
publicKeysProvider
- Provider of a public keys acceptable for a given VC hash.public HcsVcTopicListener getVcTopicListener()
public HcsVcTopicListener getVcTopicListener(java.util.function.Function<java.lang.String,java.util.Collection<com.hedera.hashgraph.sdk.crypto.ed25519.PublicKey>> publicKeysProvider)
publicKeysProvider
- Provider of a public keys acceptable for a given VC hash.


LPThumbnailView
A contextual image thumbnail view for iOS.
Features
- Easy to use
- Sleek animations
- Customizeable
- Written in the latest Swift
Installation
CocoaPods
- Install CocoaPods
Add this repo to your
Podfile
target 'Example' do # IMPORTANT: Make sure use_frameworks! is included at the top of the file use_frameworks! pod 'LPThumbnailView' end
Run
pod install
Open up the
.xcworkspace
that CocoaPods createdDone!
Carthage
To use with Carthage
Make sure Carthage is installed
brew install carthage
Add this repo to your Cartfile
github "luispadron/LPThumbnailView"
Drag the
LPThumbnailView.framework
fromMyProjDir/Carthage/Builds/iOS/LPThumbnailView
into theGeneral -> Embeded Binaries
section of your Xcode project.
Manually
- Simply download the source files from here and drag them into your project.
Usage
Simple animation
// Pick your animation style
thumbnailView.animationStyle = .enterFromRight
// Simply add an image to the thumbnail view, animation is handled for you!
thumbnailView.addImage(image)
Contextual animation
// Create/use an existing image view you would like to be animated to the position of the thumbnail.
let imgView = UIImageView(image: someImage)
// Animation from imgView to thumbnail is handled for you!
// imgView will animate to the correct frame and will be removed from the super view on completion of animation.
thumbnailView.addImageWithContext(imgView)
Documentation
Please read the docs here for more information and before posting an issue.
Example Project
Take a look at the example project here


The old site broke when we made the previous github repo private and then public again.
Hopefully this will work


Three Google searches I just made:
"ruby pretty print JSON"
"ruby write file in one line"
"bash loop through a file"
Software is glamorous y'all!
3/28/2019, 5:32:27 AM
Favs: 13
Retweets: 1
link--- layout: tweet ---
Three Google searches I just made:
"ruby pretty print JSON"
"ruby write file in one line"
"bash loop through a file"
Software is glamorous y'all!
3/28/2019, 5:32:27 AM
Favs: 13
Retweets: 1
link


{% comment %} List pages in same directory as the current page, excluding the page itself. {% endcomment %}