Initial commit: HPR Knowledge Base MCP Server
- MCP server with stdio transport for local use - Search episodes, transcripts, hosts, and series - 4,511 episodes with metadata and transcripts - Data loader with in-memory JSON storage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
125
hpr_transcripts/hpr0913.txt
Normal file
125
hpr_transcripts/hpr0913.txt
Normal file
@@ -0,0 +1,125 @@
|
||||
Episode: 913
|
||||
Title: HPR0913: Exchanging Data Podcast 1
|
||||
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0913/hpr0913.mp3
|
||||
Transcribed: 2025-10-08 04:48:46
|
||||
|
||||
---
|
||||
|
||||
My name is Dan Fry and over the next few podcasts I'm going to explain how to share data
|
||||
between your website and any number of external applications.
|
||||
The concepts and ideas used in these podcasts is based on my work to complete the open schedule
|
||||
web application and companion Android application.
|
||||
The open schedule is a web application that allows conference organizers to administer
|
||||
and publish their conference schedules.
|
||||
The data is publicly available over the internet and is able to be accessed by the Android
|
||||
application anytime the conference goes which to reference the schedule.
|
||||
These podcasts will address the following.
|
||||
In this podcast I will identify and explain the formats used for exchanging data over
|
||||
the web.
|
||||
The next podcast will explain how to build restful web services that can be used for accessing
|
||||
the data stored on the server.
|
||||
The third podcast will show how the data can be consumed by the clients.
|
||||
Lastly, I will talk about possible ways to make these solutions scale.
|
||||
To help explain these concepts I'm going to build a simple web application about a fictional
|
||||
restaurant that wants to make their menu available online as well as on an Android application.
|
||||
The same web service API can also be used by a restaurant review website that wants to
|
||||
display the restaurant's menus along with their reviews.
|
||||
All of the data and applications mentioned in these podcasts will be available on GitHub.
|
||||
Please stay tuned to the end of the podcast for information on accessing these resources.
|
||||
I'm going to start by talking about the data formats used to transfer data over the internet.
|
||||
There are numerous data exchange formats.
|
||||
For the purposes of this podcast I will focus on the few that are lightweight and easily
|
||||
parsable by the client languages.
|
||||
I would also like to mention that this will be a simplistic view of these data formats.
|
||||
The first format is the extensible markup language or more commonly known as XML.
|
||||
It is a lightweight textual data representation that was designed for simplicity and ease
|
||||
of use across the internet.
|
||||
It is easily human as well as machine readable.
|
||||
XML allows developers to create context-specific data structures that are relevant to their
|
||||
own applications.
|
||||
Opening is very straightforward.
|
||||
Opening tags are enclosed inside less than greater than symbols.
|
||||
Closing tags are enclosed in a less than and a forward slash together and a greater than
|
||||
tag.
|
||||
The opening closing tag names must match to be well formed and this includes their let
|
||||
a case as well.
|
||||
There usually is one route opening and closing tag.
|
||||
Tags can also be nested inside of parent tags.
|
||||
XML supports validation by the much older document type declarations or DTDs and XML schemas
|
||||
which is the current standard.
|
||||
However, these validation methods are out of scope for this podcast.
|
||||
If you are interested in further information regarding XML, please check out the XML page
|
||||
in Wikipedia or other sources around the internet.
|
||||
For an example, XML document for our restaurant application, please see the sample data section
|
||||
on the GitHub repository.
|
||||
The next data format is called JavaScript Object Notation or simply referred to as JSON.
|
||||
Wikipedia defines JSON as a lightweight text-based, open-standard design for human readable data
|
||||
interchange.
|
||||
It is derived from the JavaScript scripting language for representing simple data structures
|
||||
and associative arrays called objects.
|
||||
Despite its relationship to JavaScript, it is language independent with parses available
|
||||
for most languages.
|
||||
Attributes and JavaScript are denoted by opening and closing curly braces.
|
||||
Key value pairs make up the attributes inside JavaScript objects and are separated by
|
||||
commas.
|
||||
For well-forbidess, keys as well as text and date values should be enclosed in double quotes.
|
||||
Number values should not be in double quotes.
|
||||
Attribute values need not be simple types like strings or numbers.
|
||||
They can contain arrays of objects as well, which can be simple values or complex objects.
|
||||
Arrays and JavaScript are denoted with opening closing square braces and follow the same
|
||||
rules mentioned earlier.
|
||||
JSON does allow the attribute value to be a JavaScript function, but that is out of
|
||||
scope for this podcast.
|
||||
For an example, JSON document for our restaurant application, please see the sample data section
|
||||
of the GitHub repository.
|
||||
The last data type I will talk about is called JSON With Padding or simply JSON P for short.
|
||||
JSON requests cannot access data that originates on a different server than the calling application.
|
||||
When making a JSON P request, the request must contain a callback function that instructs
|
||||
the response on how it should be processed when the calling application receives it.
|
||||
The callback function is the padding in JSON P. To explain why this is important, imagine
|
||||
you are writing a website and you want to include a Google search result list in your
|
||||
page.
|
||||
In this situation, you would make a JSON P request to Google's Ajax API.
|
||||
The callback function you provide would instruct your application to draw the area on the
|
||||
page where the Google search results should be rendered.
|
||||
JSON P requests are somewhat out of scope for this podcast, but I wanted to make you aware
|
||||
of them as you may want to share your web services with more than just your own website or
|
||||
mobile applications.
|
||||
JSON P requests allow other website developers to integrate with your public data.
|
||||
Let's close out this podcast by taking a look at the data model we'll be using in our
|
||||
sample application.
|
||||
The restaurant can have any number of menus such as a breakfast menu, lunch menu, dinner
|
||||
menu, dessert menu, etc.
|
||||
Each menu can have sections like appetizers or eggs and omelets on a breakfast menu, salads,
|
||||
that type of thing.
|
||||
Each section can have any number of menu items and each item will require a name, description,
|
||||
and a price.
|
||||
The data model is very simple for this application.
|
||||
In the next podcast, I'll be looking at building restful web services that publish the data
|
||||
model up onto the internet, making it available for consumption by client applications.
|
||||
Just to reiterate, client applications could mean your website, another website, or mobile
|
||||
application.
|
||||
It could be any or all of those types of applications.
|
||||
Thank you for listening.
|
||||
My name is Dan Frey and I'm the senior web architect I had no one corporate.
|
||||
I co-host the MythTVcast podcast and I'm a regular co-host on the Linux link tech show.
|
||||
The MythTVcast podcast can be found at MythTVcast.com.
|
||||
The Linux link tech show can be found at TLLTS.org and streams live every Wednesday night at 8.30
|
||||
PM Eastern Standard Time.
|
||||
I can be reached on Google Plus, at Plus Daniel Fry, on Twitter, and Identica at DM Fry and
|
||||
on Facebook, at Facebook.com slash DM Fry.
|
||||
The projects in this presentation can be found on GitHub under github.com slash DM Fry slash
|
||||
exchanging data presentation.
|
||||
You have been listening to Hacker Public Radio at Hacker Public Radio.
|
||||
We are a community podcast network that releases shows every weekday Monday through Friday.
|
||||
Today's show, like all our shows, was contributed by an HBR listener by yourself.
|
||||
If you ever consider recording a podcast, then visit our website to find out how easy
|
||||
it really is.
|
||||
Hacker Public Radio was founded by the Digital Dark Pound and New Phenomenical and Computer
|
||||
Cloud.
|
||||
HBR is funded by the binary revolution at binref.com, all binref projects are crowd-sponsored
|
||||
by linear pages.
|
||||
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting
|
||||
needs.
|
||||
Unless otherwise stasis, today's show is released under a creative commons, attribution, share
|
||||
a life, free those own license.
|
||||
Reference in New Issue
Block a user