Padre gains first-class HTTP support

Alias on 2009-05-13T16:55:40

Over the last month or so Padre has (amazingly given the commit rate) been in something of a slow growth period.

A lot of the work has been about rounding out features, bug fixing, and dealing with various performance problems and so on. Things like a HTML POD browser, a better plugin manager, single instance support, and so on, aren't really significant features in their own right.

Mostly they're the sorts of things you just have to get right if you want to be an application of a certain size.

Most of the serious work has been happening in the plugin space, with the Catalyst plugin, spell checker, and more refinements to the plugin API to support internationalisation of plugins and integration of plugins with right-click context menus.

But I really feel like we're starting to approach the point at which all the main features of a programmer's editor like Ultraedit or Notepad++ are locked in and we can match them as a product.

In looking forwards to the direction that Padre is likely to head in next, I think it's pretty clear that the next phase is to teach Padre about the internet.

So taking as an exercise the job of finally getting the core Popularity Contest plugin to start reporting application usage to the mothership, I've implemented HTTP Task support (and it turns out to be quite elegant with a really easy to use LWP-based API).

That is, you can now write a simple class that creates objects that can push themselves into a background thread, fire a HTTP request at some server, then bring themselves back into the foreground to deal with the result.

It's simple enough that it should be really easy to layer additional levels of complexity on top of it, because instead of having to build the functionality in a completely different style of programming (like POE) you can just use any (thread-safe) regular LWP-based code and it just works.

Steffen Mueller's lovely Task API means you can also run the same logic in the foreground if you choose. And since it's based on Process.pm, you can also take the same Task classes and port them pretty quickly over be used in ordinary scripts, outside of Padre.

Here's all we need to create the Popularity Contest HTTP client class.



package Padre::Plugin::PopularityContest::Ping;

# First-generation live call to the Popularity Contest server

use strict; use warnings; use URI (); use HTTP::Request (); use Padre::Task::LWP ();

our $VERSION = '0.35'; our @ISA = 'Padre::Task::LWP';

sub new { my $class = shift;

# Prepare the information to send my %data = ( padre => $VERSION, perl => $], osname => $^O, ); if ( $0 =~ /padre$/ ) { my $dir = $0; $dir =~ s/padre$//; my $revision = Padre::Util::svn_directory_revision($dir); if ( -d "$dir.svn" ) { $data{svn} = $revision; } }

# Generate the request URL my $url = URI->new('http://perlide.org/popularity/v1/ping'); $url->query_form( \%data, ';' );

# Hand off to the parent constructor return $class->SUPER::new( request => HTTP::Request->new( GET => $url->as_string ) ); }

1;

# Copyright 2008-2009 The Padre development team as listed in Padre.pm. # LICENSE # This program is free software; you can redistribute it and/or # modify it under the same terms as Perl 5 itself.


Inside of Padre, all you need to do to use this task is something like this...

Padre::Plugin::PopularityContest::Ping->new->schedule;


Because it's so incredibly simple to make a background task that can pull data from or push data to the Interweb, I feel like we're on the cusp of a new generation of Padre plugins that can talk to all the different bits of the internet we know and love.

And with the Padre plugin competition ongoing, it's the perfect time to create something awesome with very little effort needed.


Excellent

jrockway on 2009-05-14T20:20:24

I'm glad Padre's not becoming bloated and confusing like Emacs.