15 March 2005

XML Concepts: Enterprise protocols to notify interested readers that a site now has a feed

Have you ever visited a site, but can’t find the feed? The problem isn’t that the chicklet is hidden. The problem is the site has no feed.

It would be nice if there was a way to be told when the publisher has a feed. It would save having to recheck the site. Plus, who wants to keep checking something. That’s the purpose of having XML, right?


XML Notify

Alerting readers when publishers have XML feeds


One way to look at this problem is to look at what the reader wants. Another way is to look at what the aggregator, as a service, can provide for both publishers and readers.


Enterprise brainstorming

  • What if the aggregators had an automated system that notified the readers that there was a valid feed available?

  • What if readers could load any URL [not URI] into an aggregator, and the aggregator would automatically do the checking?

  • What if the Ping-O-Matic platform or FeedMesh was set up to alert potential subscribers that the actual subscription was available?

  • What if all sites had a common URL for potential subscribers to sign-up; and the protocol then automatically converted a standard URL into a valid publication feed URI?



  • Advance sales


    Think about advance book sales at Amazon.com. Sometimes books have many sales before the book is even published. Ask Jeff Barr about advance book sales on the book he provided technical advice -- one of the Dummies guides to RSS.

    What if the FeedMesh were set up so that the system not only published new feeds, but acted as a holding system to notify potential subscribers that the feed they were looking for has finally arrived.

    Perhaps one day people will be able to load the URLs for sites they are interested in reading into their aggregator or PingOMatic, and then these services would act as an alert system: The feed you were looking for is now active.


    Aggregator


    Better yet, what if readers could load up a URL [for a site that doesn’t yet have a feed] into their aggregator; when the aggregator is notified through either PingOMatic or FeedMesh that there is a valid site, then the Aggregator would automatically convert that URL into a matching URI for the feed.


    Two-way feed


    Another approach would have a two way feed. Visitors [to the site that doesn’t yet have a feed] could sign-up on that specific site on a list.

    When that site finally gets a feed established, the site would send a direct message to the potential subscriber. The commands would be something like this: When this site has a feed, use this feed to notify the subscribers that the feed is available.


    Meshing feed


    An alternative would be to have an initial subscriber list. The potential subscribers would have a generic feed available for any platform.

    All potential subscribers would know that the given URI for any site would be www.example-standard-uri.XML; this would be the sign-up feed.

    Essentially, what would happen is the sign-up feed would be meshed with the newly-created feed; the newly-created feed’s activation would be the trigger to send the message to all the subscribers.

    This approach would require there to be a sign-up feed available for all sites; and that there be an integration or meshing capability between the sign-up feed and the actual feed that the subscribers finally were given access.


    Aggregator ping


    What could happen is that the site you visited [that didn’t yet have a feed] could ping you on your feed to your aggregator. What could happen is potential subscribers could grant prior permission to the aggregator to add this feed.

    The protocol for this addition tool could be something like this. A potential subscriber would arrive at a site without a feed; they would leave ½ of a special code on the site they visited; they would then leave the other half hidden in their aggregator.

    When the site established the feed, the site’s system would send all the ½ codes to the PingOMatic and FeedMesh to notify the aggregators.

    The aggregators would then present all the ½ codes to those who had submitted the other ½-code; the matching would ensure that the prior-notifications were matched between updated site and prior publisher.



    Standard protocols


    The downfall of this approach: If someone doesn’t yet have the configuration for a feed, would they reasonably have a system in place to let people sign-up for future feeds?

    Well, that system could be provided as a template in blogs and platforms like Drupal. If someone were to choose not to have a feed, perhaps the default position would be to generate a list on the site that allowed readers to sign-up for future feeds if they ever become available.

    Perhaps this function could be a standard package-option that the platforms could offer. Sites could be listed as not yet having RSS; when the site’s feed is available, the site would automatically send a message to the FeedMesh, PingOMatic or aggregator that the feed is now available.

    This would involve a standby list of sites waiting for feeds. The first ping from the site that established the feed would generate a command to compare the list-of-intended-subscribers with the list-of-new-feeds.


    Summary


    As more sites get added to the internet, interesting sites with potential may not yet be ready to provide a feed. Publishers are going to want a way to get back with those who found them early.

    Rather than chalk this up as a loss of business, the real opportunity is that there’s a service that could be transformed into an enterprise.

    Rather than put a site on the list of sites to recheck or monitor with tags and specialized searches, it would be far easier if there was a standard way for this interaction to occur.

    The web bots could be agents to seamlessly match those who want content and those who will one day be ready to provide that content. Some notification methods could be simple bot-pings.

    Other more complicated protocols could involve leaving cookies or codes to be later matched. Some methods could involve a simple reader-user bot that would focus on a site. Or the aggregators could act as an intermediary.

    Some readers would like a method to have the feed automatically injected to their aggregator as soon as the feed is available. Clearly, whether the content meets their continued expectations is another matter.

    Regardless the final protocols, readers want a way to automatically get notified when a new site or page finally has a feed.



    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .
    Have you ever visited a site, but can’t find the feed? The problem isn’t that the chicklet is hidden. The problem is the site has no feed.

    It would be nice if there was a way to be told when the publisher has a feed. It would save having to recheck the site. Plus, who wants to keep checking something. That’s the purpose of having XML, right?


    XML Notify

    Alerting readers when publishers have XML feeds


    One way to look at this problem is to look at what the reader wants. Another way is to look at what the aggregator, as a service, can provide for both publishers and readers.


    Enterprise brainstorming

  • What if the aggregators had an automated system that notified the readers that there was a valid feed available?

  • What if readers could load any URL [not URI] into an aggregator, and the aggregator would automatically do the checking?

  • What if the Ping-O-Matic platform or FeedMesh was set up to alert potential subscribers that the actual subscription was available?

  • What if all sites had a common URL for potential subscribers to sign-up; and the protocol then automatically converted a standard URL into a valid publication feed URI?



  • Advance sales


    Think about advance book sales at Amazon.com. Sometimes books have many sales before the book is even published. Ask Jeff Barr about advance book sales on the book he provided technical advice -- one of the Dummies guides to RSS.

    What if the FeedMesh were set up so that the system not only published new feeds, but acted as a holding system to notify potential subscribers that the feed they were looking for has finally arrived.

    Perhaps one day people will be able to load the URLs for sites they are interested in reading into their aggregator or PingOMatic, and then these services would act as an alert system: The feed you were looking for is now active.


    Aggregator


    Better yet, what if readers could load up a URL [for a site that doesn’t yet have a feed] into their aggregator; when the aggregator is notified through either PingOMatic or FeedMesh that there is a valid site, then the Aggregator would automatically convert that URL into a matching URI for the feed.


    Two-way feed


    Another approach would have a two way feed. Visitors [to the site that doesn’t yet have a feed] could sign-up on that specific site on a list.

    When that site finally gets a feed established, the site would send a direct message to the potential subscriber. The commands would be something like this: When this site has a feed, use this feed to notify the subscribers that the feed is available.


    Meshing feed


    An alternative would be to have an initial subscriber list. The potential subscribers would have a generic feed available for any platform.

    All potential subscribers would know that the given URI for any site would be www.example-standard-uri.XML; this would be the sign-up feed.

    Essentially, what would happen is the sign-up feed would be meshed with the newly-created feed; the newly-created feed’s activation would be the trigger to send the message to all the subscribers.

    This approach would require there to be a sign-up feed available for all sites; and that there be an integration or meshing capability between the sign-up feed and the actual feed that the subscribers finally were given access.


    Aggregator ping


    What could happen is that the site you visited [that didn’t yet have a feed] could ping you on your feed to your aggregator. What could happen is potential subscribers could grant prior permission to the aggregator to add this feed.

    The protocol for this addition tool could be something like this. A potential subscriber would arrive at a site without a feed; they would leave ½ of a special code on the site they visited; they would then leave the other half hidden in their aggregator.

    When the site established the feed, the site’s system would send all the ½ codes to the PingOMatic and FeedMesh to notify the aggregators.

    The aggregators would then present all the ½ codes to those who had submitted the other ½-code; the matching would ensure that the prior-notifications were matched between updated site and prior publisher.



    Standard protocols


    The downfall of this approach: If someone doesn’t yet have the configuration for a feed, would they reasonably have a system in place to let people sign-up for future feeds?

    Well, that system could be provided as a template in blogs and platforms like Drupal. If someone were to choose not to have a feed, perhaps the default position would be to generate a list on the site that allowed readers to sign-up for future feeds if they ever become available.

    Perhaps this function could be a standard package-option that the platforms could offer. Sites could be listed as not yet having RSS; when the site’s feed is available, the site would automatically send a message to the FeedMesh, PingOMatic or aggregator that the feed is now available.

    This would involve a standby list of sites waiting for feeds. The first ping from the site that established the feed would generate a command to compare the list-of-intended-subscribers with the list-of-new-feeds.


    Summary


    As more sites get added to the internet, interesting sites with potential may not yet be ready to provide a feed. Publishers are going to want a way to get back with those who found them early.

    Rather than chalk this up as a loss of business, the real opportunity is that there’s a service that could be transformed into an enterprise.

    Rather than put a site on the list of sites to recheck or monitor with tags and specialized searches, it would be far easier if there was a standard way for this interaction to occur.

    The web bots could be agents to seamlessly match those who want content and those who will one day be ready to provide that content. Some notification methods could be simple bot-pings.

    Other more complicated protocols could involve leaving cookies or codes to be later matched. Some methods could involve a simple reader-user bot that would focus on a site. Or the aggregators could act as an intermediary.

    Some readers would like a method to have the feed automatically injected to their aggregator as soon as the feed is available. Clearly, whether the content meets their continued expectations is another matter.

    Regardless the final protocols, readers want a way to automatically get notified when a new site or page finally has a feed.



    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .
    " />