HP3000-L Archives

February 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Bixby <[log in to unmask]>
Reply To:
Mark Bixby <[log in to unmask]>
Date:
Mon, 12 Feb 2001 10:12:39 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
Ken Hirsch wrote:
>
> Some people have asked about prospects for an Image module for Perl.  It
> would be fairly easy to write a module which would give raw access to the
> Image intrinsics, but I'm not sure how useful it would be.  Anybody who used
> it would have to interpret the buffer returned by DBGET by themselves and
> format a buffer for DBPUT by themselves.

I think direct Image intrinsic access would be useful in Perl, and would be the
most familiar to Image programmers.  However, an object-oriented approach would
fit better with current Perl practice, and a DBI::DBD approach would be best of
all but hardest to accomplish.

> There's no built-in support in
> Perl for zoned-decimals or packed-decimals.  Of course, Image does not keep
> any information about implied decimal points either.
>
> Still you could use integers, floating point numbers, and strings fairly
> easily.  Is that useful?

There are add-on Perl packages capable of handling packed and zoned decimal
data.  A quick web search turned up
http://www.perldoc.com/cpan/Convert/IBM390.html, but it assumes you're using
EBCDIC.

This was a very quick web search, and there may be other solutions for ASCII
data.

> My thoughts on an ideal module would be something along these lines:
>
> 1. Create a 'base' object on return from DBOPEN.
> Something like:
>   $orderbase = ImageBase->new("basename", "password", mode);

...snip...

> Any thoughts?

I defer to active Image programmers on the question of what would be the best
object-oriented implementation.

But I will pose a question -- would it be worthwhile to use an approach similar
to the Java TurboImage class library?  I'm not a Java person, and so I haven't
studied this class library in detail to know its advantages or disadvantages.
If it's a decent implementation, then it might be nice for the Perl
implementation to be similar.

The very best solution for doing Image under Perl would be to use DBI::DBD
(http://dbi.symbolstone.org/).  DBI::DBD is to Perl what ODBC is to Windows.
When Perl applications are written to use the DBI::DBD API, any database that
has a DBD module can be used for the backend.

Like ODBC, the DBI::DBD point of view is SQL/relational in nature, so it will
probably be simpler to attempt an Image/SQL DBD module than a vanilla
TurboImage DBD module that would have to implement all of the SQL/relational
stuff directly rather than calling Image/SQL.  But the e3000 ODBC vendors have
written drivers that talk to vanilla TurboImage without needing an Allbase DBE
wrapper, so this direct approach should also be possible under Perl.

There is already a DBD::ODBC module that allows Perl to access ODBC databases,
which might be an interesting thing to play with on MPE if it weren't for the
lack of an MPE ODBC *client* library (are you listening, e3000 ODBC vendors?).
--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...

ATOM RSS1 RSS2