Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Nicely played, Pudge-daddy. When I have the
    cycles, I'll post some groovy emacs macros on my journal for this service. You know, you've made Slash one step closer to Manilla now? :-)
  • To forestall abuse by posting a lot of entries, how hard will it be to stick a formkey onto journal creation? Do formkeyHandler('max_post_check', 'journals', $formkey, $msg_ref) and create a var called max_journals_allowed ... simple right?
    • Yes, we can do that, and in fact we do, but the default limit is 30.

      Although, we don't have formkeys turned on for SOAP yet ... I am going to be looking into that as time permits.
  • Hmm. Now to rewrite WWW::UsePerl::Journal to make use of SOAP.

    How does one get the recent journals via RSS anyway? Last time I looked it returned invalid URLs in the RSS.
    --
      ---ict / Spoon
    • The RSS should be fine, it has been for some time now.
      • Hmm. Hang on: is that rss for recent entries of the person or rss of the journal system as a whole?

        The url that provides incorrect urls is:
        http://use.perl.org/search.pl?content_type=rss&op=journals [perl.org]
        --
          ---ict / Spoon
        • I never knew about this RSS "feed". I was referring to http://use.perl.org/journal.pl?op=top&content_type=rss [perl.org]. If you know of bugs, please file a bug report [sf.net], else they won't get fixed!
          • Grr. Logged. After spending a few minutes trying to remember my sf password since anonymous bug reports are disabled. And SF seem to believe that this browser shouldn't be able to log into their website (it did, fwiw).

            Anyone else find the sidebar in sf just about completely useless and just taking up space? (I'm on a rev C iMac at present - not much screen real estate, and I had to regress to 8.6 to get remote access working, bloody thing).

            Come to think of it: anyone got a spare new iMac/iBook so I can ru
            --
              ---ict / Spoon
            • I should note that the 'Grr' is aimed at sf, not you. You're very lovely.
              --
                ---ict / Spoon
            • We had to disable anonymous bug reports because we had too many trolls posting bug reports. Welcome to the life of running Slashdot. :-)

              MacPerl can run the script I gave for SOAP::Lite, so that's one fun thing you can do with it! MacPerl 5.6.1r1 is due any day now, too.
              • I just need to have CPAN.pm working so I can install stuff (easily). It's currently hanging after I enter my continent (from a cmd-1 'perl -MCPAN -eshell').

                I'm probably just going about it the wrong way. I'll be looking into it on the weekend =)

                It's a nice piece of work mind you =)
                --
                  ---ict / Spoon
                • Try:

                  #!perl
                  use CPAN;
                  shell();

                  The one-liner will complete and then return, so it is not good for interactive scripts. :-) If you want an interactive command-line, get and install MPW [apple.com] (or just ToolServer, if you have something that can talk to it, like BBEdit, but MPW is superior, because ToolServer cannot call other tools, so you can't do "perl -le 'print `files`'" etc., because ToolServer itself is what allows you to call said other tools! :-).

    • You'll want to be careful in how you handle the checking for SOAP at build-time and run-time. Don't want to force people into installing something, better to give them the choice. Unless they already have it installed, of course :-).

      --rjray

      --

      --rjray

      • Hmm. I'm more of the philosophy: why have two versions of the same code?

        At the very least, the more modules that make people have SOAP client software, then the more SOAP server software there can be.

        That said, is SOAP::Lite that difficult to install?
        --
          ---ict / Spoon
        • If you're talking about using SOAP versus trying to read, parse, and post data by emulating a web client, there's no contest: use SOAP. The web client interface is guaranteed to change some day in subtle ways that will break any code you have. The SOAP interface is not. I won't say it's guaranteed to not change, but I'll try not to change it. :-)

          So yeah, if it were me, I would require users to use SOAP::Lite, or some other SOAP client module.
  • Any idea when we'll see a method for getting the ID from the username? I've already got two scripts based on this ready to go, but it pains me to see users forced to look up the UIDs :-).

    --rjray

    --

    --rjray

    • No, no idea yet. What I think might be best, currently, is to have a SOAP interface for the users stuff. So right now we have Slash::Journal::SOAP, and maybe add a Slash::Users::SOAP. One thing I am sure of is that I don't want to go further until I have a better sense of direction, so now would be a good time to give me any thoughts anyone might have on the subject. :-)
      • Hurm-- I'd love to help out with ideas, especially since this is going to be referred to several times in my SOAP chapters for the book on web services I'm writing :-). I'm not that familiar with the Slash code itself, though, and I'm not at a good place to be trying to dive into something new, either.

        I would start with a fairly basic approach that lends itself easily to adding onto later. There is no need for user-add or user-delete functions at the SOAP level, I think we can all agree that those are bett

        --

        --rjray

        • Those are similar to my thoughts, thanks.

          However, a problem I see is with how to get this all to play nicely together. What I mean is this: the uri() for Journals is "http://$host/Slash/Journal/SOAP". But the uri() for getting information about users would be something like "http://$host/Slash/Users/SOAP". Is this too unwieldy?
  • Here's something I've put together as an early example for my chapter on using the toolkits (the one that will introduce each of the SOAP and SOAP::Lite packages, before moving on to bigger code). This'll do until we get "native" RSS feeds of individual journal. :-)

    OK, scratch that. Getting the code to look right in preview is killing me. Instead, pull it down from here [blackperl.com]. Pudge, if you tell me how to make my code look purdy like yours, I'll update this...

    --rjray

    --

    --rjray

    • I've been holding off announcing it, but use the pseudotag <ECODE>. It still needs some work, and has some caveats, which I hope to deal with and announce soon.
      • Let's give it a try, then... here 'tis:


        #!/usr/bin/perl -w

        use strict;

        use SOAP::Lite;
        use XML::RSS;

        my $user = shift ||
            die "Usage: $0 userID [ usernick ]\n\nStopped";
        my $nick = shift || "#$user";

        my $host        = 'use.perl.org';
        my $uri         = "http://$host/Slash/Journal/SOAP";
        my $proxy       = "http://$host/journal.pl";

        my $journal = SOAP::Lite->uri($uri)->proxy($proxy);
        my $results = $journal->get_entries($user, 15

        --

        --rjray

  • Just used this to post a test-entry [perl.org] into my journal. It's probably about on-par with the test script pudge was using a while back, except that the path to the cookie file is UNIX-ish instead of Mac-ish (and File::Spec wouldn't really help here, because the different Netscape platforms save their user data in differently-formed paths). It also allows for command-line arguments for title and whether to allow discussion. It also allows a command-line-provided filename to provide the body, or in absence of it r

    --

    --rjray