Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: Seeking design improvements for Perl code library remote server

by daluu (Initiate)
on Dec 27, 2012 at 19:28 UTC ( #1010566=note: print w/replies, xml ) Need Help??


in reply to Re: Seeking design improvements for Perl code library remote server
in thread Seeking design improvements for Perl code library remote server

Packaging it as CPAN module is one goal I have in mind for the project. Haven't gotten to it. By the way, I'm a novice Perl developer, so have never actually built CPAN modules, nor have I developer Perl module test (*.t) files before. So that would be all new to me.

I know posting code or link to direct files is easier, but browsing an open source repo ain't that time consuming. But fine, here's the direct links:

code files
http://code.google.com/p/plrobotremoteserver/source/browse/trunk/robotremoteserver.pm

http://code.google.com/p/plrobotremoteserver/source/browse/trunk/examplelibrary.pm

http://code.google.com/p/plrobotremoteserver/source/browse/trunk/exampleremoteserver.pl

wiki page about the project & how to use
http://code.google.com/p/plrobotremoteserver/wiki/UsageInfo

list of open issues & to do items
http://code.google.com/p/plrobotremoteserver/issues/list

  • Comment on Re^2: Seeking design improvements for Perl code library remote server

Replies are listed 'Best First'.
Re^3: Seeking design improvements for Perl code library remote server
by CountZero (Bishop) on Dec 27, 2012 at 19:43 UTC
    I am not a server specialist, so I am not the right Monk to comment on that aspect of your code.

    One thing I am curious about is why you commented out use strict; use warnings;?

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
      You make a good point, that was to do quick & dirty hack to make sure that code works, functionally. Next step would be to enable strict and warning back and make sure no issues there, and fix if any.
Re^3: Seeking design improvements for Perl code library remote server
by Anonymous Monk on Dec 28, 2012 at 02:33 UTC

    Your package doesn't match the filename, see Simple Module Tutorial , the filename should match the package name.

    Instead of comments write documentation :) Tutorials: POD in 5 minutes and maybe

    See Modern Perl and Class::Inspector AND Howto create a Moose baseclass/superclass/contract? Moose equivalent of Module::Pluggable? Favorite way to create base/super class?

    You might start with

    module-starter --author="David Luu" --email=man...mail.com --license=LGPL --module=RobotRemoteServer,RobotRemoteServer::Frontier,RobotRemoteServer,RobotRemoteServer::RPCXMLServer

    Added to MANIFEST: Changes
    Added to MANIFEST: ignore.txt
    Added to MANIFEST: lib/RobotRemoteServer.pm
    Added to MANIFEST: lib/RobotRemoteServer/Frontier.pm
    Added to MANIFEST: lib/RobotRemoteServer/RPCXMLServer.pm
    Added to MANIFEST: Makefile.PL
    Added to MANIFEST: MANIFEST
    Added to MANIFEST: README
    Added to MANIFEST: t/00-load.t
    Added to MANIFEST: t/boilerplate.t
    Added to MANIFEST: t/manifest.t
    Added to MANIFEST: t/pod-coverage.t
    Added to MANIFEST: t/pod.t
    Created starter directories and files
    

    Then maybe write something like


    package RobotRemoteServer;
    use Class::Inspector;

    sub get_keyword_names { my ($self) = @_; my $class = $self->lib; my @methods = Class::Inspector->methods( $class, 'public' ); return \@methods; } sub run_keyword { my $self = shift; my ($stdout, $stderr) = capture { ... }; } sub start_server { my $self = shift; $self->backend->start_server; }

    package RobotRemoteServer::Frontier; sub _shut_down_request { RobotRemoteServer::Frontier sub start_server { my ($self) = @_; my $svr = Frontier::Daemon->new( methods => { get_keyword_names => sub { $self->get_keyword_names(@_) }, run_keyword => sub { $self->run_keyword($_[0], eval{@{$_[1]}}) } +, stop_remote_server => sub { $srv->_shutdown('yes please'); $self->schedule_shutdown; return; }, .... } sub schedule_shutdown { my $self = shift; my $url = $self->url; if( eval { require threads; } ){ threads::async { sleep 5; require Frontier::Client; Frontier::Client->new( 'url' => $url )->call('stop_remote_s +erver'); }; } elsif( eval { require Proc::Background; } ){ Proc::Background->new( $^X, '-e', q{ use Frontier::Client; sleep 5; my $url = shift @ARGV; Frontier::Client->new( 'url' => $url )->call('stop_remote_server'); exit; }, $url, ); } } sub Frontier::Daemon::_shutdown { my( $self, $true ) = @_; ${*$self}{'_Frontier::Daemon::_shutdown'} = !!$true if $true; return ${*$self}{'_Frontier::Daemon::_shutdown'} ; } sub Frontier::Daemon::accept { ## monkeypatch package Frontier::Daemon; my $self = shift; if( $self->_shutdown ){ close $self; return; } else { return $self->SUPER::accept; } }

    To handle shutdown in similar way as https://robotframework.googlecode.com/hg/tools/remoteserver/robotremoteserver.py you could monkeypatch shutdown, but writing your own frontier deaemon ( Frontier::Daemon::Forking ) is probably the correct way to do it

    backend is the new argument, RobotRemoteServer::Frontier by default

    use RobotRemoteServer; #my $rob = RobotRemoteServer->new (qw' host localhost port 666 '); my $rob = RobotRemoteServer->new (qw' host localhost port 666 backend Frontier lib ExampleLibrary '); $rob->start_server;

    Maybe it makes more sense for backends to be named as RobotRemoteServer::Backend::Frontier ...

    But that is a start, pod beats comments, seperate backends into seperate modules, use existing modules for introspection , has-a not isa-a ...

    Future direction:
    maybe Moo/Moose or Badger for accessors/mutators...
    Maybe POE server ( ex Hopkins::Plugin::RPC ), ex?Catalyst::Plugin::Server::XMLRPC, Plack for ideas
    maybe cooperation with Daemon::Generic, AnyEvent::XMLRPC, ...

    If I were more knowledgeable, I might make better suggestions ;)

      Thanks, that's good constructive comment/criticism. I'll look into those when I have time. I hope to get more feedback from others, if there is any more feedback that can be offered.

      One question to add, if anyone can provide feedback: how might I best test this Perl remote server implementation and package the tests for CPAN module distribution? And any tutorial links for testing Perl code?

      Well, I procrastinated until now with looking into the details of the suggested code. Now that I'm really looking, not being a Perl guru, I'm confused with how the breakdown of the code is between the backend and the server interface. I was thinking of having the server (frontend) component be packaged as RobotRemoteServer::Server or keep it as RobotRemoteServer as it originally was.

      But right now, I don't see how the backend links to the frontend in the suggested code in terms of things like using statements (to use front/back end package in the other) along with how the actual object instance shares method & properties between the packages.

      Can you/someone elaborate? FYI, I've never built multi-file packages, only single file contained packages.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1010566]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2018-02-25 06:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    When it is dark outside I am happiest to see ...














    Results (312 votes). Check out past polls.

    Notices?