![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The wheels just keep on turning
Nov. 25th, 2005 08:24 pmAndy Ward is now in St Kitts, and in just over a week I'm outta here to Vegas. Good. I shall try to update from there (yes, I know that I'm on holiday even with pictures .. the things that I do for an audience).
I spent a bit of time at work today trying to work out how to put out my newsletter as an RSS feed. Now, you probably think that this is easy. But, since it's five years since I created a web page, and since I don't even use an aggregator at home (or at work) it wasn't as easy as you think.
Part of the problem was that most of the sites I went to for guidance were starting from the premise that (a) you would give the information away, and that (b) the reason you would do this would be to drive traffic to your web site.
The standard format was "xml page with descriptions, linked to html pages with the full story on your web site"
These assumptions were seriously flawed, in that they were, er, utterly wrong. It's a subscription newsletter, and it has no base web site as such. And the last thing I want is to drive traffic there. I want as little traffic as possible, but for what traffic there is to be paying a lot of money for the information provided.
After I had spent three hours or so getting my head around how the whole thing was put together, I reckoned that I could use the following business model.
1) A "secret" web address (in fact, this already exists, via web space that I have available to me)
2) No html pages, all xml, with one xml page per subscriber. Apart from that, each xml page would be the same, consisting of that day's newsletter.
3) Fiendishly long codes for each xml page, which you supply to your subscribers, one code (i.e., one page) per subscriber.
4) So, when their sub lapses, you just remove that xml page from the web site.
Of course, a subscriber could pass the RSS subscription code (the URL they put into their aggregator) onto someone else, but this would show up in the increase in hits on that xml page (because each subscriber has a unique RSS url). At the moment they can forward the e-mailed newsletter without me having the faintest idea that they are doing so.
I can easily write a macro in Word that will save the newsletter as (say) 100 separately named xml files. So all I need is the software to automatically upload those files as soon as they are saved.
Obviously this doesn't work for a mass circulation publication.
The alternative was to have 12 xml pages, all the same, and with fiendishly long coded addresses, which were allocated according to the month that a company's subscription ran out. This would make uploading easier, but would make checking on cheating harder.
I spent a bit of time at work today trying to work out how to put out my newsletter as an RSS feed. Now, you probably think that this is easy. But, since it's five years since I created a web page, and since I don't even use an aggregator at home (or at work) it wasn't as easy as you think.
Part of the problem was that most of the sites I went to for guidance were starting from the premise that (a) you would give the information away, and that (b) the reason you would do this would be to drive traffic to your web site.
The standard format was "xml page with descriptions, linked to html pages with the full story on your web site"
These assumptions were seriously flawed, in that they were, er, utterly wrong. It's a subscription newsletter, and it has no base web site as such. And the last thing I want is to drive traffic there. I want as little traffic as possible, but for what traffic there is to be paying a lot of money for the information provided.
After I had spent three hours or so getting my head around how the whole thing was put together, I reckoned that I could use the following business model.
1) A "secret" web address (in fact, this already exists, via web space that I have available to me)
2) No html pages, all xml, with one xml page per subscriber. Apart from that, each xml page would be the same, consisting of that day's newsletter.
3) Fiendishly long codes for each xml page, which you supply to your subscribers, one code (i.e., one page) per subscriber.
4) So, when their sub lapses, you just remove that xml page from the web site.
Of course, a subscriber could pass the RSS subscription code (the URL they put into their aggregator) onto someone else, but this would show up in the increase in hits on that xml page (because each subscriber has a unique RSS url). At the moment they can forward the e-mailed newsletter without me having the faintest idea that they are doing so.
I can easily write a macro in Word that will save the newsletter as (say) 100 separately named xml files. So all I need is the software to automatically upload those files as soon as they are saved.
Obviously this doesn't work for a mass circulation publication.
The alternative was to have 12 xml pages, all the same, and with fiendishly long coded addresses, which were allocated according to the month that a company's subscription ran out. This would make uploading easier, but would make checking on cheating harder.
