Loading ...
Sorry, an error occurred while loading the content.

My Userland on the Blackberry (was Re: [radio-userland] Re: External programmatic access to RU?)

Expand Messages
  • Dave Winer
    Coool. I like that idea a lot. Now we ve even got a marketing slogan. It seems like the functionality could all be managed in a Website Tool.
    Message 1 of 3 , Feb 20, 2001
      Coool. I like that idea a lot. Now we've even got a marketing slogan.

      It seems like the functionality could all be managed in a Website Tool.


      Give Radio an email address to check, and specify a frequency (every N

      Require a password? Enter it here.. Repeat. (The password would be the
      subject of the message?)

      So far so good.

      Now what would the format of the incoming message be?

      Would you want a response?

      How about editing an item?

      These are the hard questions, the implementation is trivial, Radio already
      has a verb for reading mail, tcp.getMail, and it works, it's already been
      tested in production, it's how I do the Mail Pages for Scripting News.


      ----- Original Message -----
      From: "Scott Loftesness" <sjl@...>
      To: <radio-userland@yahoogroups.com>
      Sent: Tuesday, February 20, 2001 10:05 AM
      Subject: [radio-userland] Re: External programmatic access to RU?

      > I agree.
      > I want something similar: MUOTB = My Userland on the Blackberry!
      > Scott
      > --- In radio-userland@y..., "Dave Winer" <dave@u...> wrote:
      > > Brilliant!!
      > >
      > > Dave
      > >
      > >
      > > ----- Original Message -----
      > > From: "David Davies" <d.a.davies@b...>
      > > To: <radio-userland@y...>
      > > Sent: Monday, February 19, 2001 4:32 PM
      > > Subject: [radio-userland] Re: External programmatic access to RU?
      > >
      > >
      > > > > How does an external program make a call into RU?
      > > >
      > > > I email my copy of RU to make it do things I want when I'm away
      > from my
      > > > office.
      > > >
      > > > Set up an email account and have RU poll it every so often, or
      > every
      > > minute
      > > > as I do when I want to communicate with RU when I'm on the road.
      > Then,
      > > send
      > > > an email to your special RU account containing commands you want
      > RU to
      > > > execute. RU checks the email account, and executes whatever it
      > finds
      > > > (security note below). This isn't anew trick, others have done
      > it many
      > > > times before. I think someone wrote some kind of email daemon for
      > Frontier
      > > a
      > > > while ago.
      > > >
      > > > By commands, I don't mean script steps, though there's no reason
      > why you
      > > > couldn't do this (but think of the security issues first).
      > > >
      > > > A command I use is:
      > > >
      > > > Subject: add to manila
      > > > Message: Whatever I type into the message of the email gets added
      > to my
      > > > Manila site, time stamped.
      > > >
      > > > This is great if you want to add weblog items when you're either
      > on the
      > > road
      > > > or away from a web browser. My trusty Nokia 7110 comes in handy
      > for this.
      > > I
      > > > can add a weblog entry from where ever I am, in the middle of a
      > field, up
      > > a
      > > > tree, it doesn't matter. Some of you may remember emailing my
      > weblog some
      > > > months ago last time I mentioned it on this list.
      > > >
      > > > You can do just about anything you like with this trick. I also
      > use it to
      > > > check other email accounts and forward selected messages to my
      > phone.
      > > > Actually, I use Frontier for this but it amounts to the same
      > thing.
      > > >
      > > > For security, I only allow RU or Frontier to accept email from
      > addresses I
      > > > specify. You can also add a password to your email messages if
      > you're
      > > really
      > > > worried.
      > > >
      > > > Other ideas for communicating into RU... Why not use the built in
      > web
      > > server
      > > > and trigger actions via forms you set up in an RU tool. That way
      > your copy
      > > > of RU is listening for instructions all the time, and it doesn't
      > matter
      > > what
      > > > platform you communicate from. It's called CGI and has been
      > around since
      > > the
      > > > dawn of the web ;-)
      > > >
      > > > Cheers,
      > > >
      > > > David.
      > > >
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > radio-userland-unsubscribe@egroups.com
      > > >
      > > >
      > > >
      > To unsubscribe from this group, send an email to:
      > radio-userland-unsubscribe@egroups.com
    • Jeremy Paul Bowers
      Dave Winer, you said. . . ... I ve been thinking about this a bit. I think it might be worthwhile to go whole hog and do a e-mail responder framework; it s
      Message 2 of 3 , Feb 20, 2001
        Dave Winer, you said. . .
        >Now what would the format of the incoming message be?

        I've been thinking about this a bit. I think it might be worthwhile to go
        "whole hog" and do a e-mail responder framework; it's what I was going to do if
        Userland didn't do anything. The first line of the e-mail (or maybe the
        subject, though I think I want to reserve that for later) would be the
        "responder name" that we want to invoke, and the rest of the message would be
        handled by the responder. The tool could ship with some default responders, and
        we developers could add more as we desired, much as RU works with the web.

        I think it might also be good to parse "command-line arguments" for the
        command, perhaps put them into a list the responder can get at, similar to
        parsing GET or POST arguments.

        An example Manila post command:

        manila-post [manila website name] [optional password]

        [the message to be posted, exactly as it will be posted]

        The manila-post responder would be passed two things: The list of arguments (in
        this case the site we are posting to), and a string containing the remainder of
        the message. Presumably, we've already told manila-post what the website is,
        so we don't need to send _all_ the website information.

        The thing is for all the actions people might want to take, it's hard to define
        a uniform interface.

        MUOTD-add-channel http://[rss channel]
        [message body ignored]

        might add a channel into MUOTD remotely, even if you can't get to the website
        behind a firewall.

        For extra bonus points...

        XML-RPC [optional XML-RPC version]

        <methodCall> ... </methodCall>

        Do we want a response? In general, I think we do. The responder should probably
        be able to return a response, which the framework would mail back. So, the
        XML-RPC handler would take the command, process it, convert the result into
        XML-RPC results, and return that, which the framework would then e-mail back to
        the originator.

        The other major feature that may not seem immediately useful, but would really
        make this useful to developers is the ability to send e-mails with unique
        things in the subject line and then make sure they are still there when the
        e-mail comes back. I'm sure you've seen this when subscribing to a list; they
        send you an e-mail with a unique subject so you the sender can be certain it's
        not being faked. I have not fully considered how to do this yet, but it seems
        The Right Thing.

        (The use I have in mind for this is to allow people to e-mail my copy of Radio
        Userland a password, so it can upload things to their site via FTP. I want to
        make sure that when they reply, they are replying directly to my e-mail, not
        just sending the system stuff in an attempt to crack it.)

        Yeah, it's a little more complicated then the original manila-poster, but I can
        think of a _lot_ of things we may want a responder for. (Interesting thought:
        "Return all e-mail responders this copy of Radio Userland can handle", implying
        some sort of registration system. If we want that feature, it needs to be in
        at the beginning.)

        I hate to restrict something this powerful, yet simple to use, unnecessarily.

        (For use by The People, we might default the responder to be manila-post and
        default the site posted to, so all this complexity condenses down to "Mail this
        address and it will appear on your manila site" for people who don't care for
        everything else that they might be able to do.)

        >How about editing an item?

        manila-get-message [site] [number or path] [password if so configured]
        [no body]


        manila-edit-message [site] [same number or path] [password if configured]

        [The message being edited]

        "manila-get-message" just happens to return an e-mail that is already formatted
        for sending to "manila-edit-message", which will post it. The easiest thing to
        do is copy & paste that message (or reply, if you can convince your e-mail
        program not to put quote chars on the reply), and just send it back. This would
        be cool.

        Please forgive me if this is a bit grandiose... if userland doesn't do it, I'll
        do at least part of this someday (though it will be a while, time is scarce
        right now). I've got to for my own system, I might as well do it "right" the
        first time so others can use it.

        - Jeremy Bowers jerf@... http://www.jerf.org -
        - http://irights.editthispage.com : -
        - * Eternal Vigilance is the Price of Freedom * -
      • Jeremy Paul Bowers
        So, if I may translate Dave s Scripting News comment today, Interesting idea, but what is it good for? :-) So, a half-hearted defense (half-hearted because
        Message 3 of 3 , Feb 21, 2001
          So, if I may translate Dave's Scripting News comment today, "Interesting idea,
          but what is it good for?" :-) So, a half-hearted defense (half-hearted because
          it's not like I'm really attached to the idea):

          First, Manila posting is obviously the "killer feature", and if that's all you
          really want, then a full responder is massive overkill. But I did sit down and
          think about what a responder would do that people might actually be interested

          - Synchronizing a mailing list and a discussion group. A responder could be set
          up to pick up, say, this message, which is going out on the mailing list but
          can't be seen in the DG, and post the contents into the DG, where we (or
          rather, the webmaster) control the data. (Actually, when you take this step,
          RU+Manila might as well run the whole shebang and skip eGroups entirely.)

          - News item routing. MUOTD is basically a system which takes in news in many
          formats (RSS, user entered, scriptingNews2.xml) and can output in many formats
          (RSS, manila website (I think?), RU weblog). I'm on several mailing lists with
          actual news and information (like CRYPTO-GRAM), and it might be nice to forward
          an e-mail item, edit it in my e-mail program, and post it by sending it to RU.
          Would definately fit into the MUOTD modus operandi. (Remotely adding channels
          was kinda silly, yes :-) )

          - Manila news item posting. More complicated then a straight story post.

          - Post to _RU weblog_, post to live outline, post to directory, post to
          upstreaming directory, as distinct from simply dumping a message to Manila.
          There are a lot of places we might e-mail something to (and the somewhat
          regrettable prevalence of firewalls makes this desirable) _other_ then a new
          Manila message, and it starts getting kludgy to add each of those in. Adding to
          a directory on a Manila site is particularly interesting, because it's
          extremely difficult for a normal user to add it by hand, as it involves
          editting OPML by hand in a textarea.

          - There are still a few commands you might concievably want to fire off in RU,
          even if it's on the wrong side of a firewall. Re-render something (weblog,
          etc.), esp. after an update. Start the music playing (esp. if you've got it set
          to stream automaticall), stop the music.

          A bit more fanciful:

          - Push updates. Rather the RU querying updates.userland.com,
          updates.userland.com mails the updates to those who want that. Might fix a
          future scaling issue.

          - Spam reply processing. Turn Radio Userland into the world's most powerful
          spam machine. Grab a list of e-mail addresses, start sending mail, and keep an
          eye on the reply box. When somebody replies, RU can automatically process the
          results, and since it checks every minute, you might actually get one of the
          replies before your mailbox is shut down. Automatically send people who reply
          with a remove request your spam on "How To Avoid Spam for just $19.95". Ask
          people to mail you their credit card info and have Radio Userland automatically
          order things from Amazon with that info. With the responder in place, it would
          be easy to make Radio Userland the most versatile spam mailer on the
          planet! Just imagine the pitch you could make on the front page of

          Again, if none of these are compelling, and I really think that if nothing
          else, that spam bit really should have sold you :-) , then I totally agree the
          responder is overkill. I just thought I'd play devil's advocate for a bit. :-)

          - Jeremy Bowers jerf@... http://www.jerf.org -
          - http://irights.editthispage.com : -
          - * Eternal Vigilance is the Price of Freedom * -
        Your message has been successfully submitted and would be delivered to recipients shortly.