[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [drmaa-wg] Perl module namespace & WG blessing :-)
He's right. Depending on which idea we are talking about.
First, I love the DRMAA-C thing. It sounds a perfect solution to my problem
and will allow me to deliver the CPAN module by the time SGE6.0 is released
(I hope). As I said, I have to clear it with the UC regents and get a UCRL,
which I anticipate it will be granted but can't guarantee it won't take more
than a few weeks. I realize now I may have talked about this in a private
thread. But, I work for LLNL (Lawrence Livermore National Laboratory), in
the Bioinformatics group. My project, demanded a Perl API for conversing
with a job scheduler, and I found DRMAA, and here I am. My project is in
favor of me making the work public, so I plan to do so. It could really
help everyone, DRMAA efforts, my project efforts, the Open source grid
efforts, etc. I'm really excited about it and glad to be a part.
Next, I don't know enough about the JAVA, .NET approach yet, I'll do some
reading to catch up. But I can forsee two methods of approach , both seems
valid to me...
Scheduler::DRMAA::Simple
Modular, not OO. Providses simpler interface to attributes, automatic
multiple date format support for job start/deadline times, not bound to
DRMAA spec but adds additional functionality and because it is not spec'd
its development progress at the rate the author(s) can code. As for naming,
Hrabri, you're right about Lite it is a conventional method to denote
simpler interface, but so is "Simple", eg. XML::Simple, LWP::Simple
(search using search.cpan.org for others ). XML::Simple is a classic
example, because it builds upon the more rigorous XML::Parser. XML::Simple
is not a spec'd out formal thing, neither is Parser for that matter, but
modules in a similar vein to Parser are SAX based and formally spec'd.
"Lite" to me gives the feeling of a subset of functionality to the original,
so I like "Simple" better.
Scheduler::DRMAA
A spec'd Perl binding to DRMAA, must try to stay current with the DRMAA
spec as it evolves. Must itself be spec'd before implementation. Perhaps
automatically handles versioning. I don't know the discussions behind
versioning in the past, but I'm making the assumption it is like XHTML or
say JavaScript in that if you state you want to use v1.0, the implementation
must support it or fail and if you try to use 1.2 features in a 1.0
implementation then they fail.
----- Original Message -----
From: "Daniel Templeton" <dan.templeton@sun.com>
To: "DRMAA-WG" <drmaa-wg@gridforum.org>
Sent: Thursday, March 25, 2004 8:33 AM
Subject: Re: [drmaa-wg] Perl module namespace & WG blessing :-)
> I highly recommend against an OO Perl binding. That would just be
> sadistic/masochistic, and it wouldn't buy you anything. Perl's native
> variable types more than provide the constructs needed by DRMAA.
>
> Daniel
>
> Rajic, Hrabri wrote:
>
> > Tim,
> >
> >Have you given any thought of having OO or flat approach?
> >
> >If OO, we need to attempt to synchronize the Perl module with the .NET
> >and Java approaches.
> >
> >-Hrabri
> >
> >
> >-----Original Message-----
> >From: owner-drmaa-wg@gridforum.org [mailto:owner-drmaa-wg@gridforum.org]
> >On Behalf Of Rajic, Hrabri
> >Sent: Thursday, March 25, 2004 9:57 AM
> >To: DRMAA-WG
> >Cc: Tim Harsch
> >Subject: RE: [drmaa-wg] Perl module namespace & WG blessing :-)
> >
> >
> >I am in favor of consistency. Since you are building on top of drmaa.h
> >i.e.
> >C implementation use of DRMAA name is almost automatic:
> >
> >- there would be just one DRMAA Perl 1:1 translation module
> >- you are operating within GGF environment
> >
> >Any other derivation could take suggested qualifications or additional
> >subclassing.
> >I am not sure what name would be appropriate and in the spirit of Perl
> >right now.
> >::Simpler could be a misnomer. Simplified Perl packages usually have
> >name Lite in them and
> >there is no skimping in ::Simpler.
> >That is the first line of reasoning about the name.
> >
> >
> >
> >A slightly different approach would, IMHO, view work even better. We
> >could call the SWIG translation
> >Scheduler::DRMAA-C and more Perl friendly version as Scheduler:DRMAA.
> >DRMAA-C is 1:1 mapping of the C implementation and we do not need much
> >discussion there, but to come up with DRMAA module I would like to
> >discuss it a bit more on the list, so we could come up with a consensus.
> >Having said that, I am not sure how to get few Perl experts to provide a
> >response to the draft from the Perl language angle.
> >
> >
> >-Hrabri
> >
> >-----Original Message-----
> >From: owner-drmaa-wg@gridforum.org [mailto:owner-drmaa-wg@gridforum.org]
> >On Behalf Of Tim Harsch
> >Sent: Wednesday, March 24, 2004 8:59 PM
> >To: DRMAA-WG
> >Subject: [drmaa-wg] Perl module namespace & WG blessing :-)
> >
> >The Perl module's list suggested I name the module
> >Scheduler::DRMAA
> >
> >( That is if the working group lets me use the DRMAA name ). Speaking
> >of
> >which, what will I need to do exactly to get the group's blessing?
> >Andreas
> >mentioned a drafting up a formal spec, like the group has done for the C
> >&
> >Java binding. If I were, how long might that process take?
> >
> >I'm considering just releasing it under my own name, like perhaps
> >Scheduler::AnyDRM. I would of course reference DRMAA, and point the
> >user to
> >the specs, etc. But I also feel that the module, being such a close
> >match
> >to the C binding is not a good Perl module. There are things I could do
> >different to make it much simpler to use, and was considering creating a
> >sub-class module for that, like Scheduler::DRMAA::Simpler ( or
> >Scheduler::AnyDRM::Simple ). Or perhaps, just creating
> >Scheduler::AnyDRM::Simple, with no documented access to the drmaa_*
> >functions which would be employed by the module. Don't get me wrong I
> >would
> >love to do this with 100% WG blessing, and am willing to put forth the
> >work
> >to draw up the spec, if required. But, I will only have a limited
> >amount of
> >blessing from the project that pays my salary.
> >
> >Is there some speedy way I might get through this, like finishing the
> >POD
> >documentation so that it doesn't leave out any important data from the
> >spec,
> >and getting that blessed?
> >
> >Tim Harsch
> >Computer Scientist
> >Lawrence Livermore National Laboratory
> >(925) 423-1135
> >
> >
> >
>
> --
> *************************************************************
> * Daniel Templeton ERGB01 x60220 *
> * Staff Engineer, Sun N1 Grid Engine *
> *************************************************************
> * "When heroes go down they fall in flame, *
> * So don't expect any slow and careful settling of blame." *
> * -Suzanne Vega, "When Heroes Go Down" *
> *************************************************************
>
>