HOME > RSS > TECHNOLOGY > Scripting News

R S S : Scripting News


PageRank : 3 %

VoteRank :
(0 - 0 vote)





tagsTags: , , , , , , , , , , , , , ,


English

RSS FEED READER



One enclosure per item or multiple?

21 May[ —]

Over the years one of the criticisms of RSS 2.0, the version of RSS that enabled podcasting, is that it only allowed one enclosure per item.

This was a deliberate decision. I was aware at the time that there was a choice. I went with the one-to-one correspondence. There were two reasons, a design question and to keep it simpler for developers and podcast listeners.

  1. Suppose you allowed an arbitrary number of enclosures. Wouldn't you want to be able to describe each? If so, an enclosure would morph from being a simple three-attribute element, to a structure. What would be the new sub-elements? One obvious one would be . How about a title? A date? Category? Author? I'm sure you see where this is going. We just created a new inside an enclosure. And could an enclosure have an enclosure? Why not? Isn't that more powerful? (The reason usually given for having more enclosures.)
  2. The second reason is that you made life more complicated for the aggregator developer. When they look for an enclosure they somehow have to decide which of the multiple enclosures the user wants, or offer a choice to the user. Does the user really care what format the podcast is in? When I'm listening what I want is to hear the podcast. You want me to choose? My life is already too complicated. Too much software interrupts the flow of my thought with questions I have no interest in. 

Re Evan Williams and JSON Feed

21 May[ —]

I'm doing a switchover from the current 1999.io-based blogging home page to my new software, which is codenamed Old School. In advance of the switchover I'm doing real writing over there, stuff that belongs in the main Scripting News RSS feed. So I'm going to run a couple of them here in the this post. 

Re the NYT profile of Evan Williams

Re today's profile of Evan Williams and Medium in the NYT.

A few off-the-top-of-my head thoughts...

The best art ignores money. It's driven by the desire of a human to express what's inside. "I am human and I have something to say."

I wish Medium had strived to make crazy-great editing software, and had created a server that they operated for free, and free of advertising, and open source with a liberal license that let others build new kinds of collaborative systems with great editing at its core.

How do you make money from this? We don't have an opinion about that.

Think of it as a way for a man who made billions from the open web to give back. It was never about any individual's greatness or worth, it was and is about our need as a species to apply our collective minds to our evolution. We still have fundamental changes to make for our species to survive.

I'd add that the whole idea of a Great Thinker solving our problems is itself part of the problem. It worked for us until we conquered and controlled nature. Now we have to find a new purpose for ourselves, a new mission. 

Re JSON feed

People have asked what I think of JSON feed...

My longtime friend and collaborator, Brent Simmons, is one of the two guys who designed the format. In fact I am in Seattle right now visiting Brent, talking about another project, though of course we have discussed JSON feed. I knew it was coming. Brent and I emailed about it about a month ago.

My opinion is pretty neutral. Kind of a shoulder shrug. It reminds me of the slogan from Battlestar Galactica. "All of this has happened before and will happen again."

The hype around this effort reminds me of the hype at the start of Atom. Thankfully the personal stuff does not seem to be coming along with it this time.

Is this something we should be focusing on?

I think we have to work on climate change and the fascism that's trying to boot up in the US. Our systems for news suck, and there are obvious ways to improve them if we put our minds to it. And I think a new incompatible feed format not only doesn't move us toward solving those problems, in a very small way (not worth worrying about) it moves us away from solving them. By using bandwidth that could be used to foster working-together, perhaps. By making things that would otherwise interop, not interop.

If developers have a hard time using XML in their apps, if that's the problem, why not attack it right there? Work to make it easier. I work in Node and the browser, and in both places XML and JSON are equally easy to use. The same could be done for any environment. In fact in the browser, XML is integrated deeply into the programming model, because the web is made out of XML.

As a developer of feed reading software, if any new format gains traction, my software will support the format. I don't believe in locking users in or out. So a new incompatible format makes my life slightly more difficult. But once the work is done, it moves out of the way, hopefully never to be thought of again.

As a writer, and developer of feed-creating software I am going to stick with good old RSS 2.0 with the source namespace. It has served me well, and doesn't want for any features. If it did, I would just add them to the namespace.

One more thought, a few years ago we played around with the idea of JSONified RSS, a simple translation of the XML elements and attributes to JSON. Two observations. 1. It didn't invent new names for things that already exist. 2. It didn't catch on.

See my Manifesto for standards-makers for other general thoughts. 


davereader is the engine of River5

18 May[ —]

I've long wanted a JavaScript package that made it easy to write quick apps that do stuff with feeds. 

I write them all the time, but I always have to start over from the beginning, create a parser, then catch the new items as they come in, and do whatever it is I have to do, usually move the bits to another service like Twitter, or Slack or whatever. There are so many possible applications.

When I was doing this, I realized I was solving a problem that was already solved, in my River software, but it wasn't configured correctly to make this easy. It was faster just to crib the code and start from scratch.

Finally, I have it set up so that this works. So the beauty in this is in the apps, not the engine. It's a solved problem that can now be used to solve new problems.

What's new

I moved the core functionality of River5 into an NPM package that makes it possible to use River5 in any Node app. The name of the package is davereader. The repository is of course on GitHub. 

The main change to River5 is that instead of containing the core, it accesses it through NPM as it does for many of its other core functions. 

To the River5 user very little if anything changes. That's written up on the River5 site. If you have questions, please ask them on the River5 mail list or in a comment here

What's easier?

The Hello World app for davereader watches a few feeds. When a new item comes in it writes its JSON representation to a calendar-structured folder. 

That's the pattern that many of the davereader apps will follow. For a set of feeds, flow all new items to some other place. That's basically what RSS does, so that's what an application that uses RSS will most likely do. ;-)

Why davereader?

The more obvious names were taken. 

If I had my druthers I'd call this node-reader because that's what it does, brings industrial strength feed reading to Node. 

But davereader isn't bad. It's the reader that Dave wrote. :balloon:


Experimenting with a personal Twitter

16 May[ —]

An experiment with blogging and news.

As you know, I've been working on yet another version of Scripting News. This one is based on the way the site worked at the very beginning. Very free form, written in an outliner, I get to use all the features of HTML, the posts can be long or short, have titles or not, include as many links as I want. 

I've been blogging over there for the last few days and it feels good. It also feels good to write longer pieces here, using 1999.io. So I will use both ways to blog, and they will be integrated. If the design is right, you won't know where a story came from. 

Combining flows on Slack

Along the way an item made it onto my todo list to try flowing all the links to a Slack group. So yesterday I cobbled something together quickly that flows all the links from four of my feeds into one flow on Slack. The four feeds are:

  1. The main Scripting News feed.
  2. My Radio3-based linkblog feed.
  3. The feed from my new Old School blog.
  4. The feed from my Flickr account.

I thought this might be an interesting prototype for a Personal Twitter, one where an individual, someone who's very active at collecting links (me) and writing quick posts (again, me) and taking pictures (you get the idea), posts things as they come to his or her attention. I set it up and invited a few friends. I really like it. 

You can request an invite

So I want to invite other people to join the group. It's not for commenting, it's just for reading, but there's no way to configure Slack for that, so it has to be on the honor system. I set up a channel called Chatroom for people to talk about stuff, if they want to. The comment guidelines for Scripting News will apply there. 

If you've made it this far, great! 

And if you'd like to request an invite, post your email address to this form, with a comment about how long you've been reading Scripting News, and an idea of how much you're interested in this Personal Twitter idea.


My experience with Google *LINE Corp

15 May[ —]

I've been getting fraud alerts from my credit card company about charges from an entity known as GOOGLE *LINE Corp. 

On the first reports, I just assumed they were from Google, the amounts were small, always either $1.99 and $3.99, so I just said they were okay. But they kept coming. 

I did a search and see lots of people upset about it. So I called the credit card company, and turns out I've had charges from them, adding up to $200 already this year.

Turns out LINE is a Korean chat app, like WeChat, I've been told.

So I called the credit card company, killed the card. Usually they're easy to deal with but they've added all kinds of fake security checks (meaningless stuff, easy to fake) that make it a miserable experience. And the people who used to be in the US are now in the Philippines. You can tell. There's a difference between dealing with people from your own culture. It's taken me a few hours to figure out what's going on and it's been pretty miserable.

I think we're going to be doing a lot more of this..

And Google -- if you can hear me, please try to vet the companies using your services. This one is already famous.


Old School and WebSockets for River5

13 May[ —]

A couple of projects to report progress on.

1. Back in the beginning, I wrote my blog with an outliner, and I could put posts of all length in the feed. Posts with titles or no titles. Any HTML I wanted. Then came Twitter and Google Reader and they squeezed my blog to almost nothing. Facebook then took out what was left. Try to write for all of them, that's the empty set. So fuck it, let's go back to the beginning before all that michegas, and have a notepad where my ideas flow and maybe some of them make it into the silos, or not. 

That's the concept.

And the implementation is coming along. 

The project is called Old School. 

Here's a link to the prototype page. You should be able to read it on a mobile device or desktop screen. Not sure when this will become the official blog, I hope soon. 

2. A number of months ago I added WebSockets to River5 but never documented it or wrote sample code. 

Now there's an example app

It hooks up to my River5 server, and displays the JSON text for every item it discovers. 

The source is on GitHub. 

That's all for now.

Enjoy your weekend! ;-)


Manifesto: Rules for standards-makers

10 May[ —]

I've used all kinds of formats and protocols in a long career as a software developer.

I also have created a few, and have had to fight to keep them independent and unowned, with varying degrees of success. This set of rules represents what I've learned.

If we work together on a project based on open tech, these are the principles I will try to stick to. I wanted to put all this in one place, so I can pass it along to future software developers. 

Rule #1: Interop is all that matters

The only reason we have open formats and protocols is so our software can interoperate.

Why interop?

We want interop so that our users are free to move.

So our products compete on the basis of performance, features and price, and not lock-in.

This is as basic as the Hippocratic Oath that doctors take.

It honors and respects the users of our products.

There are tradeoffs in standards

There are few absolutes in standards work, some rules even contradict others, so you have to think, and strike a balance.

Software matters more than formats (much)

Too often people try to design a format first, and then make software that conforms to the format. You might get some good demos. But not much chance of developing a standard that way.

Users matter even more than software

People choose to interop because it helps them find new users. If you have no users to offer, there won't be much interest in interop.

One way is better than two

No matter how much better the new way is, you'll still have to support the old way.

Fewer formats is better

If you can replace two formats with one, without breakage or loss of interop, then I say go for it.

Removing complexity from the world is always good.

Think of this like code factoring, but on a larger scale.

This is 1/2 of Postel's robustness principle -- be conservative in what you send.

Fewer format features is better

If you want to add a feature to a format, first carefully study the existing format and namespaces to be sure what you're doing hasn't already been done. If it has, use the original version. This is how you maximize interop.

Perfection is a waste of time

I've witnessed long debates over which name is better than another.

I once led a standards discussion beginning with this rule: We always had to come up with the worst possible name for every element. That way when someone said "I think foo is better" (and they did) we could all laugh and say that's exactly why we won't use it.

It totally doesn't matter what we call it. We can learn to use anything. There are more important things to spend time on.

Think of people whose first language isn't English. To them the names we choose are symbols, they don't connote anything.

Write specs in plain English

I write for people who have brains, like to think, are educated, care about interop. I understand that people reading specs are not computers.

Explain the curiosities

I also try to explain why things are as they are because people seem to be interested. But only after explaining how it works and providing an example.

If practice deviates from the spec, change the spec

In writing the spec for RSS 0.91, I found that a lot of the limits imposed by the earlier spec were being ignored by developers. So I left the limits out of 0.91 spec. No one complained.

After RSS 2.0, the format was frozen, so no more adjustments based on practice.

No breakage

Version 2 of your format should be backward compatible. This means that a version 1 file is a valid version 2 file.

Don't break the installed base. (Not that you can. There are still lots of people running XP even though Microsoft said it was over. And that's a commercial product, not a standard.)

Freeze the spec

At some point, when the new ideas have slowed to a trickle, and as a base of compatible software develops, freeze the spec, but provide an extension mechanism so new ideas have an outlet.

Developers need a foundation to build on, one that is fixed and isn't moving.

Keep it simple

Beware of open formats that are impossible to fully support.

XML-RPC could be fully supported in a few days. You could never fully support SOAP. I believe this is no accident. Large companies crafted SOAP so they could say they were open without interoperating with competitors. The goal of XML-RPC was to make it easy to interop.

Developers are busy

Now you've got a popular product and your data formats are open and documented, you are encouraging your competitors to be compatible.

Next thing to do is to create a toolkit in at least one popular language that shows how to support the format. Real working code can help fill in the blanks for the spec. Some developers will use the sample code without ever looking at the spec. I know I do.

Mail lists don't rule

There's a weird bit of psychology that seems to happen on mail lists set up to discuss interop. The people there feel like they can make decisions that the world will then obey. You can hear it how people talk. They seem to believe they have arrived at the top of the pyramid and now they are masters of the universe. Actually, they're just people on a mail list. No one, not even the other people on the list, care what you think.

Same is true for real world conferences.

Praise developers who make it easy to interop

I'm thinking of Slack. They didn't have to make it so easy, but they did anyway. It's the web way, it's the strong way. They're saying they want their users to be free to leave at any time. That they should stay with Slack because their product is the best, not because they have to stay.

Thanks for listening!

If you have comments or questions, you can use the GitHub group

Just post an issue related to this document. 

There's also a slide-show version of this, suitable for presentations.

And thanks for making it this far.

Dave


My Mac seems happy!

8 May[ —]

Knock wood, I think I have all the glitches out of the setup of my main Mac. No rainbow cursor, and Time Machine is backing up the system. And I have a huge amount of space on my external boot disk. These were the main problems with my previous setup.

To get it done, it wasn't enough to get the new external drive set up, I also had to format the internal drive. And that was a little tricky, for me at least. 

So I'm happy to have a radically nice desktop computer setup. Finally. 

It should not have to be this hard...

A picture of a slice of cheese cake.


How a podcast should advertise its RSS feed

6 May[ —]

This came up in a thread on Twitter, and I realized there is no write-up or even an example of a good way to advertise an RSS feed on your podcast page.

Here's the problem. If you put a link to the RSS feed alongside the links to iTunes and Stitcher and whatever else, you're going to get a bunch of emails from users about how your site is broken. I know, because I've gotten those emails. 

So you're in an organization and the boss says Do something about this! So what's the easiest thing to do, considering that you're an overworked web content person? Remove the link. You feel a little guilty because you know you're removing a resource that you yourself would want there, but this is your job, and you have to keep the boss happy. 

I just want you to know that I understand. I get it.

So here's the optimal answer. 

Create a simple page that says "This is a link to our RSS feed. It's used by developers and hobbyists to build their own listeners and it helps support innovation on the internet." 

Right below that put a plain link to the RSS feed. Assume the user knows to right-click. Remember this is for developers and hobbyists. 

Point to that page from your podcast landing page, using the RSS icon alongside all the others. 

Tell your boss it's good for flow, will get more listeners, especially technical people who you can hire to help me (the overworked web content person), and yes you probably still will get some emails because some people like to write emails, but you will know that you're feeding the commons, and helping other developers innovate, and also keeping podcasting from being controlled by silos. All that from a little icon! :-)

Here's an example of such a page...

One more thing, there is a standard way to advertise an RSS feed, and it's supported by all the browsers. It works too, and if you have a choice between one or the other, use the standard way. 


Do good now

6 May[ —]

If you're running a campaign -- think about what you can do now that makes the world a better place. Your campaign is drawing huge attention and money. Most of it is wasted on lies and attack ads. Take a small portion of the money and attention to start doing now the things you hope to do when you're in office. This will turn out to be good politics too. And the process can continue after you're elected. it will make sure you're not too deeply ensconced in the bubble of government. And if you lose, at least you can say the campaign was good for everyone, people who voted for you and people who voted for the other guy.


0 | 10 | 20










mirPod.com is the best way to tune in to the Web.

Search, discover, enjoy, news, english podcast, radios, webtv, videos. You can find content from the World & USA & UK. Make your own content and share it with your friends.


HOME add podcastADD PODCAST FORUM By Jordi Mir & mirPod since April 2005....
ABOUT US SUPPORT MIRPOD TERMS OF USE BLOG OnlyFamousPeople MIRTWITTER