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

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

Expand Messages
  • 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 1 of 3 , Feb 20, 2001
    • 0 Attachment
      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 2 of 3 , Feb 21, 2001
      • 0 Attachment
        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.