DOCSLIB.ORG

Podgen Documentation Release 1.1.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Podgen Documentation Release 1.1.0 PodGen Documentation Release 1.1.0 Lars Kiesow and Thorben Dahl Mar 06, 2020 Contents 1 Contents 3 1.1 Background................................................3 1.1.1 Philosophy...........................................3 1.1.2 Scope..............................................4 1.1.3 Why the fork?..........................................4 1.1.4 Roadmap............................................6 1.1.5 License.............................................6 1.2 Usage Guide...............................................6 1.2.1 Installation...........................................6 1.2.2 Podcasts.............................................7 1.2.3 Episodes............................................. 10 1.2.4 RSS............................................... 15 1.2.5 Full example.......................................... 15 1.3 Advanced Topics............................................. 16 1.3.1 Using PubSubHubbub..................................... 16 1.3.2 Adding new tags........................................ 19 1.4 Contributing............................................... 22 1.4.1 Setting up............................................ 22 1.4.2 Testing............................................. 22 1.4.3 Values.............................................. 23 1.4.4 The Workflow.......................................... 23 1.5 API Documentation........................................... 23 1.5.1 podgen.Podcast......................................... 24 1.5.2 podgen.Episode......................................... 33 1.5.3 podgen.Person......................................... 37 1.5.4 podgen.Media.......................................... 38 1.5.5 podgen.Category........................................ 42 1.5.6 podgen.warnings........................................ 43 1.5.7 podgen.util........................................... 44 2 External Resources 45 Index 47 i ii PodGen Documentation, Release 1.1.0 (https://travis-ci.org/tobinus/python-podgen) (http://podgen.readthedocs.io/en/latest/?badge=latest) Are you looking for a clean and simple library which helps you generate podcast RSS feeds from your Python code? Here is how you do that with PodGen: from podgen import Podcast, Episode, Media # Create the Podcast p= Podcast( name="Animals Alphabetically", description="Every Tuesday, biologist John Doe and wildlife" "photographer Foo Bar introduce you to a new animal.", website="http://example.org/animals-alphabetically", explicit=False, ) # Add some episodes p.episodes+=[ Episode( title="Aardvark", media=Media("http://example.org/files/aardvark.mp3", 11932295), summary="With an English name adapted directly from Afrikaans" '-- literally meaning"earth pig" -- this fascinating' "animal has both circular teeth and a knack for" "digging.", ), Episode( title="Alpaca", media=Media("http://example.org/files/alpaca.mp3", 15363464), summary="Thousands of years ago, alpacas were already" "domesticated and bred to produce the best fibers." "Case in point: we have found clothing made from" "alpaca fiber that is 2000 years old. How is this" "possible, and what makes it different from llamas?", ), ] # Generate the RSS feed rss=p.rss_str() You don’t need to read the RSS specification, write XML by hand or wrap your head around ambiguous, undocumented APIs. PodGen incorporates the industry’s best practices and lets you focus on collecting the necessary metadata and publishing the podcast. PodGen is compatible with Python 2.7 and 3.4+. Warning: As of March 6th 2020 (v1.1.0), PodGen does not support the additions and changes made by Apple to their podcast standards since 2016, with the exception of the 2019 categories. This includes the ability to mark episodes with episode and season number, and the ability to mark the podcast as “serial”. It is a goal to implement those changes in a new release. Please refer to the Roadmap. Contents 1 PodGen Documentation, Release 1.1.0 2 Contents CHAPTER 1 Contents 1.1 Background Learn about the “why” and “how” of the PodGen project itself. 1.1.1 Philosophy This project is heavily inspired by the “for humans” approach of the Requests (https://requests.readthedocs.io) library, which features an API that is designed to give the developer a great user experience. This is done by finding a suitable scope and abstraction level, and designing the API so it supports the developer’s vocabulary and their mental model of how the domain works. For example, instead of using the names of XML tags like “itunes:image”, a more relevant name, here simply “image”, is used. Another example is the duration of a podcast episode. In XML terms, this is put into an “itunes:duration” tag which exists outside of the “enclosure” tag, which holds the filename and file size. In PodGen, the filename, file size, file type and audio duration are all placed together in a Media instance, since they are all related to the media itself. The goal has been to “hide” the messy details of the XML and provide an API on top which uses words that you recognize and use daily when working with podcasts. To be specific, PodGen aims to follow the same PEP 20 (https://www.python.org/dev/peps/pep-0020/) idioms as Re- quests (https://requests.readthedocs.io/en/master/user/intro/#philosophy): 1. Beautiful is better than ugly. 2. Explicit is better than implicit. 3. Simple is better than complex. 4. Complex is better than complicated. 5. Readability counts. To enable this, the project focuses on one task alone: making it easy to generate a podcast. 3 PodGen Documentation, Release 1.1.0 1.1.2 Scope This library does NOT help you publish a podcast, or manage the metadata of your podcasts. It’s just a tool that accepts information about your podcast and outputs an RSS feed which you can then publish however you want. Both the process of getting information about your podcast, and publishing it needs to be done by you. Even then, it will save you from hammering your head over confusing and undocumented APIs and conflicting views on how different RSS elements should be used. It also saves you from reading the RSS specification, the RSS Best Practices and the documentation for iTunes’ Podcast Connect. Here is an example of how PodGen fits into your code: 1. A request comes to your webserver (using e.g. Flask (https://palletsprojects.com/p/flask/)) 2. A podcast router starts to handle the request. 3. The database is queried for information about the requested podcast. 4. The data retrieved from the database is “translated” into the language of PodGen, using its Podcast, Episode, People and Media classes. 5. The RSS document is generated by PodGen and saved to a variable. 6. The generated RSS document is made into a response and sent to the client. PodGen is geared towards developers who aren’t super familiar with RSS and XML. If you know ex- actly how you want the XML to look, then you’re better off using a template engine like Jinja2 (even if friends don’t let friends touch XML bare-handed) or an XML processor like the built-in Python El- ementTree API (https://docs.python.org/3/library/xml.etree.elementtree.html#module-xml.etree.ElementTree). If you just want an easy way to create and manage your podcasts, check out systems like Podcast Generator (http://www.podcastgenerator.net/). 1.1.3 Why the fork? This project is a fork of python-feedgen (https://github.com/lkiesow/python-feedgen) which cuts away everything that doesn’t serve the goal of making it easy and simple to generate podcasts from a Python program. Thus, this project includes only a subset of the features of python-feedgen (https://github.com/lkiesow/python-feedgen). And I don’t think anyone in their right mind would accept a pull request which removes 70% of the features ;-) Among other things, support for ATOM and Dublin Core is removed, and the remaining code is almost entirely rewritten. A more detailed reasoning follows. Read it if you’re interested, but feel free to skip to the Usage Guide. Inspiration The python-feedgen (https://github.com/lkiesow/python-feedgen) project is alright for creating general RSS and ATOM feeds, especially in situations where you’d like to serve the same content in those two formats. However, I wanted to create podcasts, and found myself struggling with getting the library to do what I wanted to do, and I frequently found myself looking at the source to understand what was going on. Perhaps the biggest problem is the awkwardness that stems from enabling RSS and ATOM feeds through the same API. In case you don’t know, ATOM is a competitor to RSS, and has many more capabilities than RSS. However, it is not used for podcasting. The result of mixing both ATOM and RSS include methods that will map an ATOM value to its closest sibling in RSS, some in logical ways (like the ATOM method rights setting the value of the RSS property copyright) and some differ in subtle ways (like using (ATOM) logo versus (RSS) image). Other methods are more complex (see link). They’re all confusing, though, since changing one property automatically changes another implicitly. They also cause bugs, since it is so difficult to wrap your head around how one interact with another. This is the inspiration for forking python-feedgen (https://github.com/lkiesow/python-feedgen) and rewrite the API, without mixing the different standards. 4 Chapter 1. Contents PodGen Documentation, Release 1.1.0 Futhermore, python-feedgen (https://github.com/lkiesow/python-feedgen) gives you a one-to-one mapping to the re- sulting XML elements. This means that you must learn the RSS and podcast standards, which include many legacy elements you don’t really need. For example, the original RSS spec includes support for an image, but that image is required to be less than 144 pixels wide (88 pixels being the default) and 400 pixels high (remember, this was year 2000). Itunes can’t have any of that (understandably so), so they added their own itunes:image tag, which has its own set of requirements (images can be no smaller than 1400x1400px!). I believe the API should help guide the users by hiding the legacy image tag, and you as a user shouldn’t need to know all this. You just need to know that the image must be larger than 1400x1400 pixels, not the history behind everything.
Load more

Recommended publications
  • Architecture of the World Wide Web, First Edition Editor's Draft 14 October 2004
    Architecture of the World Wide Web, First Edition Editor's Draft 14 October 2004 This version: http://www.w3.org/2001/tag/2004/webarch-20041014/ Latest editor's draft: http://www.w3.org/2001/tag/webarch/ Previous version: http://www.w3.org/2001/tag/2004/webarch-20040928/ Latest TR version: http://www.w3.org/TR/webarch/ Editors: Ian Jacobs, W3C Norman Walsh, Sun Microsystems, Inc. Authors: See acknowledgments (§8, pg. 42). Copyright © 2002-2004 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements. Abstract The World Wide Web is an information space of interrelated resources. This information space is the basis of, and is shared by, a number of information systems. In each of these systems, people and software retrieve, create, display, analyze, relate, and reason about resources. The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support. Status of this document This section describes the status of this document at the time of its publication.
    [Show full text]
  • Samsung Podcasts RSS Spec 060921
    Samsung Podcasts RSS Spec June 2021 SAMSUNG C&S SAMSUNG CONFIDENTIAL Introduction The purpose of this document is to provide technical guidelines to podcasters for optimal exposure of their RSS feeds on Samsung Podcasts. Notes • Submitting feeds to Samsung Podcasts will not prevent submission to other platforms. • Samsung Podcasts will not re-cache or re-host audio content. • These guidelines are meant to reflect requirements used by other standard podcast platforms. • Some requirements are meant to support future V2 features, marked in red. Samsung Proprietary and Confidential 2 RSS Feed Requirements Samsung Proprietary and Confidential 3 Feed Requirements: Podcast “Podcast” is defined as an ordered collection of episodes. A podcast must: • Be described by a valid RSS feed that conforms to RSS 2.0 specifications • Be freely reachable, not requiring login, token, or similar information • Be uniquely defined by its <link> field (Samsung Podcasts will handle a podcast as a new podcast if this field changes) Samsung Podcasts will use podcast metadata accessed via the <link> field. Podcasters will need to ensure that artwork files are valid, reachable, and accurate. Samsung Podcasts may choose to cache artwork and metadata to optimize performance, but will not cache or re-host audio data. Unreachable or uninterpretable RSS feeds will be disabled by Samsung Podcasts. Please ensure that explicit words in Podcast titles and descriptions are censored in your metadata before submitting. Failure to censor explicit words could result in suspension of content from the platform. 4 Feed Requirements: Episode “Episode” is defined as an audio segment expressed through an audio file. Podcast episodes must: • Be uniquely defined by its <guid> field (Samsung Podcasts will handle an episode as new if the GUID is new or changed) • Be freely reachable, not requiring login, token, or similar information • Provide a supported audio file format (mp3, m4a, aac, wav, ogg) Samsung Podcasts will use episode metadata accessed via the <link> field and episode <guid> field.
    [Show full text]
  • Supplement 211: Dicomweb Support for the Application/Zip Payload
    5 Digital Imaging and Communications in Medicine (DICOM) Supplement 211: 10 DICOMweb Support for the application/zip Payload 15 20 Prepared by: Bill Wallace, Brad Genereaux DICOM Standards Committee, Working Group 27 1300 N. 17th Street Rosslyn, Virginia 22209 USA 25 Developed in accordance with work item WI 2018 -09 -C VERSION: 19 January 16, 2020 Table of Contents Scope and Field of Application ........................................................................................................................................ iii 30 Open Questions ....................................................................................................................................................... iii Closed Questions .................................................................................................................................................... iiii 8.6.1.3.1 File Extensions ................................................................................................................................. viv 8.6.1.3.2 BulkData URI ................................................................................................................................... viv 8.6.1.3.3 Logical Format ........................................................................................................................................ viv 35 8.6.1.3.4 Metadata Representations ...................................................................................................................... viv Scope and Field of Application
    [Show full text]
  • Fast and Scalable Pattern Mining for Media-Type Focused Crawling
    Provided by the author(s) and NUI Galway in accordance with publisher policies. Please cite the published version when available. Title Fast and Scalable Pattern Mining for Media-Type Focused Crawling Author(s) Umbrich, Jürgen; Karnstedt, Marcel; Harth, Andreas Publication Date 2009 Jürgen Umbrich, Marcel Karnstedt, Andreas Harth "Fast and Publication Scalable Pattern Mining for Media-Type Focused Crawling", Information KDML 2009: Knowledge Discovery, Data Mining, and Machine Learning, in conjunction with LWA 2009, 2009. Item record http://hdl.handle.net/10379/1121 Downloaded 2021-09-27T17:53:57Z Some rights reserved. For more information, please see the item record link above. Fast and Scalable Pattern Mining for Media-Type Focused Crawling∗ [experience paper] Jurgen¨ Umbrich and Marcel Karnstedt and Andreas Harthy Digital Enterprise Research Institute (DERI) National University of Ireland, Galway, Ireland fi[email protected] Abstract 1999]) wants to infer the topic of a target page before de- voting bandwidth to download it. Further, a page’s content Search engines targeting content other than hy- may be hidden in images. pertext documents require a crawler that discov- ers resources identifying files of certain media types. Na¨ıve crawling approaches do not guaran- A crawler for media type targeted search engines is fo- tee a sufficient supply of new URIs (Uniform Re- cused on the document formats (such as audio and video) source Identifiers) to visit; effective and scalable instead of the topic covered by the documents. For a scal- mechanisms for discovering and crawling tar- able media type focused crawler it is absolutely essential geted resources are needed.
    [Show full text]
  • Reuters Institute Digital News Report 2020
    Reuters Institute Digital News Report 2020 Reuters Institute Digital News Report 2020 Nic Newman with Richard Fletcher, Anne Schulz, Simge Andı, and Rasmus Kleis Nielsen Supported by Surveyed by © Reuters Institute for the Study of Journalism Reuters Institute for the Study of Journalism / Digital News Report 2020 4 Contents Foreword by Rasmus Kleis Nielsen 5 3.15 Netherlands 76 Methodology 6 3.16 Norway 77 Authorship and Research Acknowledgements 7 3.17 Poland 78 3.18 Portugal 79 SECTION 1 3.19 Romania 80 Executive Summary and Key Findings by Nic Newman 9 3.20 Slovakia 81 3.21 Spain 82 SECTION 2 3.22 Sweden 83 Further Analysis and International Comparison 33 3.23 Switzerland 84 2.1 How and Why People are Paying for Online News 34 3.24 Turkey 85 2.2 The Resurgence and Importance of Email Newsletters 38 AMERICAS 2.3 How Do People Want the Media to Cover Politics? 42 3.25 United States 88 2.4 Global Turmoil in the Neighbourhood: 3.26 Argentina 89 Problems Mount for Regional and Local News 47 3.27 Brazil 90 2.5 How People Access News about Climate Change 52 3.28 Canada 91 3.29 Chile 92 SECTION 3 3.30 Mexico 93 Country and Market Data 59 ASIA PACIFIC EUROPE 3.31 Australia 96 3.01 United Kingdom 62 3.32 Hong Kong 97 3.02 Austria 63 3.33 Japan 98 3.03 Belgium 64 3.34 Malaysia 99 3.04 Bulgaria 65 3.35 Philippines 100 3.05 Croatia 66 3.36 Singapore 101 3.06 Czech Republic 67 3.37 South Korea 102 3.07 Denmark 68 3.38 Taiwan 103 3.08 Finland 69 AFRICA 3.09 France 70 3.39 Kenya 106 3.10 Germany 71 3.40 South Africa 107 3.11 Greece 72 3.12 Hungary 73 SECTION 4 3.13 Ireland 74 References and Selected Publications 109 3.14 Italy 75 4 / 5 Foreword Professor Rasmus Kleis Nielsen Director, Reuters Institute for the Study of Journalism (RISJ) The coronavirus crisis is having a profound impact not just on Our main survey this year covered respondents in 40 markets, our health and our communities, but also on the news media.
    [Show full text]
  • Open Search Environments: the Free Alternative to Commercial Search Services
    Open Search Environments: The Free Alternative to Commercial Search Services. Adrian O’Riordan ABSTRACT Open search systems present a free and less restricted alternative to commercial search services. This paper explores the space of open search technology, looking in particular at lightweight search protocols and the issue of interoperability. A description of current protocols and formats for engineering open search applications is presented. The suitability of these technologies and issues around their adoption and operation are discussed. This open search approach is especially useful in applications involving the harvesting of resources and information integration. Principal among the technological solutions are OpenSearch, SRU, and OAI-PMH. OpenSearch and SRU realize a federated model to enable content providers and search clients communicate. Applications that use OpenSearch and SRU are presented. Connections are made with other pertinent technologies such as open-source search software and linking and syndication protocols. The deployment of these freely licensed open standards in web and digital library applications is now a genuine alternative to commercial and proprietary systems. INTRODUCTION Web search has become a prominent part of the Internet experience for millions of users. Companies such as Google and Microsoft offer comprehensive search services to users free with advertisements and sponsored links, the only reminder that these are commercial enterprises. Businesses and developers on the other hand are restricted in how they can use these search services to add search capabilities to their own websites or for developing applications with a search feature. The closed nature of the leading web search technology places barriers in the way of developers who want to incorporate search functionality into applications.
    [Show full text]
  • Describing Media Content of Binary Data in XML W3C Working Group Note 4 May 2005
    Table of Contents Describing Media Content of Binary Data in XML W3C Working Group Note 4 May 2005 This version: http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504 Latest version: http://www.w3.org/TR/xml-media-types Previous version: http://www.w3.org/TR/2005/NOTE-xml-media-types-20050502 Editors: Anish Karmarkar, Oracle Ümit Yalç&#305;nalp, SAP Copyright © 2005 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. > >Abstract This document addresses the need to indicate the content-type associated with binary element content in an XML document and the need to specify, in XML Schema, the expected content-type(s) associated with binary element content. It is expected that the additional information about the content-type will be used for optimizing the handling of binary data that is part of a Web services message. Status of this Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This document is a W3C Working Group Note. This document includes the resolution of the comments received on the Last Call Working Draft previously published. The comments on this document and their resolution can be found in the Web Services Description Working Group’s issues list. There is no technical difference between this document and the 2 May 2005 version; the acknowledgement section has been updated to thank external contributors.
    [Show full text]
  • 2016 Technical Guidelines for Digitizing Cultural Heritage Materials
    September 2016 Technical Guidelines for Digitizing Cultural Heritage Materials Creation of Raster Image Files i Document Information Title Editor Technical Guidelines for Digitizing Cultural Heritage Materials: Thomas Rieger Creation of Raster Image Files Document Type Technical Guidelines Publication Date September 2016 Source Documents Title Editors Technical Guidelines for Digitizing Cultural Heritage Materials: Don Williams and Michael Creation of Raster Image Master Files Stelmach http://www.digitizationguidelines.gov/guidelines/FADGI_Still_Image- Tech_Guidelines_2010-08-24.pdf Document Type Technical Guidelines Publication Date August 2010 Title Author s Technical Guidelines for Digitizing Archival Records for Electronic Steven Puglia, Jeffrey Reed, and Access: Creation of Production Master Files – Raster Images Erin Rhodes http://www.archives.gov/preservation/technical/guidelines.pdf U.S. National Archives and Records Administration Document Type Technical Guidelines Publication Date June 2004 This work is available for worldwide use and reuse under CC0 1.0 Universal. ii Table of Contents INTRODUCTION ........................................................................................................................................... 7 SCOPE .......................................................................................................................................................... 7 THE FADGI STAR SYSTEM .......................................................................................................................
    [Show full text]
  • What Is a Podcast? the Term Podcast Comes from a Combination of Ipod and Broadcast
    What is a podcast? The term podcast comes from a combination of iPod and Broadcast. Thus, it is a broadcast that is created to be listened to on a digital device of some kind: iPod or other MP3 player, SmartPhone, iPad or other tablet, or computer. A podcast can be entertainment, music, drama, sermon, health, business, or other coaching information. It is an MP3 file just like any song that you may listen to – only much larger. When you subscribe to my blog, you can simply listen by clicking the Play button embedded in the blog post. However, you may want to listen away from your computer. You can subscribe to podcasts and have them automatically delivered to your MP3 player for you to listen to whenever you wish. Or you can go out and listen from a site like iTunes or Stitcher. If you have a SmartPhone or Tablet, you can install an app that will collect these podcasts for you. Subscribing in iTunes You must have an iTunes account and have iTunes on your device. Go to this link: https://itunes.apple.com/us/podcast/finding-your-groove-kathleen/id829978911 That will bring you to this screen Click the button that says “View in iTunes” That opens this window in iTunes Click the Subscribe button just underneath the photo. To share this podcast with someone else, click the drop-down arrow just to the right of the Subscribe button. That will give you these share options: Tell a Friend, Share on Twitter, Share on Facebook, Copy Link (allows you to manually e-mail someone).
    [Show full text]
  • A Nova Mídia Podcast: Um Estudo De Caso Do Programa Matando Robôs Gigantes
    UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE COMUNICAÇÃO CENTRO DE FILOSOFIA E CIÊNCIAS HUMANAS JORNALISMO A NOVA MÍDIA PODCAST: UM ESTUDO DE CASO DO PROGRAMA MATANDO ROBÔS GIGANTES TÁBATA CRISTINA PIRES FLORES RIO DE JANEIRO 2014 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE COMUNICAÇÃO CENTRO DE FILOSOFIA E CIÊNCIAS HUMANAS JORNALISMO A NOVA MÍDIA PODCAST: UM ESTUDO DE CASO DO PROGRAMA MATANDO ROBÔS GIGANTES Monografia submetida à Banca de Graduação como requisito para obtenção do diploma de Comunicação Social/ Jornalismo. TÁBATA CRISTINA PIRES FLORES Orientador: Octávio Aragão RIO DE JANEIRO 2014 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE COMUNICAÇÃO TERMO DE APROVAÇÃO A Comissão Examinadora, abaixo assinada, avalia a Monografia A nova mídia podcast: um estudo de caso do programa Matando Robôs Gigantes, escrita por Tábata Flores. Monografia examinada: Rio de Janeiro, ___ de _______________ de 2014. Comissão Examinadora: Orientador: Prof. Octávio Aragão Doutor em Artes Visuais pela Escola de Belas Artes - UFRJ Departamento de Comunicação - UFRJ Prof. Fernando Mansur Doutor em Comunicação pela Escola de Comunicação - UFRJ Departamento de Comunicação - UFRJ Lúcio Luiz Corrêa da Silva Doutorando em Educação pela Universidade Estácio de Sá Programa de Pós-Graduação em Educação (Tecnologias de Informação e Comunicação nos Processos Educacionais) – Universidade Estácio de Sá RIO DE JANEIRO 2014 FICHA CATALOGRÁFICA FLORES, Tábata. A nova mídia podcast: um estudo de caso do programa Matando Robôs Gigantes. Rio de Janeiro, 2014. Monografia (Graduação em Comunicação Social/Jornalismo) – Universidade Federal do Rio de Janeiro – UFRJ, Escola de Comunicação – ECO. Orientador: Octávio Aragão Orientadora: Raquel Paiva de Araújo Soares FLORES, Tábata. A nova mídia podcast: um estudo de caso do programa Matando Robôs Gigantes.
    [Show full text]
  • Media Type Application/Vnd.Oracle.Resource+Json
    New Media Type for Oracle REST Services to Support Specialized Resource Types O R A C L E WHITEPAPER | M A R C H 2 0 1 5 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Contents Introduction 3 Conventions and Terminology 3 Core terminology 3 Singular Resource 4 Collection Resource 8 Exception Detail Resource 13 Status Resource 14 Query Description Resource 15 create-form Resource 16 edit-form Resource 17 JSON Schema 18 IANA Considerations 28 References 28 Change Log 28 2 | ORACLE WHITEPAPER: NEW MEDIA TYPE FOR ORACLE REST SERVICES TO SUPPORT SPECIALIZED RESOURCE TYPES Introduction This document defines a new media type, application/vnd.oracle.resource+json, which can be used by REST services to support the specialized resource types defined in the following table. Resource Type Description Singular Single entity resource, such as an employee or a purchase order. For more information, see “Singular Resource.” Collection List of items, such as employees or purchase orders. See “Collection Resource.” Exception Detail Detailed information about a failed request. See “Exception Detail Resource.” Status Status of a long running job. See “Status Resource.” Query description Query syntax description used by client to build the "q" query parameter.
    [Show full text]
  • Social Media Solution Guide
    Social Media Solution Guide Deploy Social Messaging Server with an RSS Channel 9/30/2021 Deploy Social Messaging Server with an RSS Channel Deploy Social Messaging Server with an RSS Channel Contents • 1 Deploy Social Messaging Server with an RSS Channel • 1.1 Prepare the RSS Channel • 1.2 Configure the Options • 1.3 Interaction Attributes • 1.4 Next Steps Social Media Solution Guide 2 Deploy Social Messaging Server with an RSS Channel Warning The APIs and other features of social media sites may change with little warning. The information provided on this page was correct at the time of publication (22 February 2013). For an RSS channel, you need two installation packages: Social Messaging Server and Genesys Driver for Use with RSS. The Driver adds RSS-specific features to Social Messaging Server and does not require its own Application object in the Configuration Server database. You can also create a Custom Media Channel Driver. Important Unlike some other eServices components, Social Messaging Server does not require Java Environment and Libraries for eServices and UCS. Prepare the RSS Channel 1. Deploy Social Messaging Server. 2. Run the installation for Genesys Driver for Use with RSS, selecting the desired Social Messaging Server object: Social Media Solution Guide 3 Deploy Social Messaging Server with an RSS Channel Select your Social Messaging Server Object 3. Locate the driver-for-rss-options.cfg configuration file in the \<Social Messaging Server application>\media-channel-drivers\channel-rss directory. 4. In Configuration Manager, open your Social Messaging Server Application, go to the Options tab, and import driver-for-rss-options.cfg.
    [Show full text]