C to Perl API implementation problems

[OeufMayo]

I am currently using for my job a full-blown Server-side javascript API to communicate to a Document Managment Database. This database uses a proprietary protocol to communcate with the client, and this protocol is available on CPAN.

What I'd like to do is to get rid of the Server-side javascript as it is really a complete hell to make something over 5000 lines work reliably in this language. So after browsing the documentation of the database, I came across the C and the language independent specifications of the API.
This API doesn't specify performance issues except for trivial (at least in perl) operations.

After a heavy rewriting of the mentionned module, I was able to implement successfully the key features of the API as a proof of concept. Now that I'm beginning the real work, the question is wether or not it is okay to stray from the original API specifications to fit a "normal" perl implementation. By "normal perl implementation", I'm thinking of the way one would write a module designed specifically for perl, relying on perl built-in funtionnalities.

As an example, there's a method which returns the length of a string. Should it be implemented or is it okay to just rely on perl's length function? I know that I could make a 'fake' length method call which will just send back the length of the string like:

sub length {
   my ($self, $string) = @_;
   return length $string;
}

But I want to avoid promoting it in the documentation and not using it afterwards...

The other issue I'm facing is the error-handling. The API defines an 'Error' object which is sent back after each call to the server. I don't find it really easy to use and I was thinking of doing an error handling 'à la DBI' with the RaiseError function, leaving the user the ability to ignore it, but if it enables it, he doesn't have to handle the error object as it has been already processed by the internals.

My point is to know if it is considered good programming style to break one's API to fit the language it is implemented in, especially in Perl, where many shortcuts are available? Any thoughts on these various points would be more than welcome.

I eventually plan to release that module to the Perl community, to people who don't necessarily know the standard API. I'm trying to come up with a solution where a perl programmer would feel "at home" with the interface, but not scarying too much programmers who knew the API before.

Update: (hopefully) explained a bit more precisely my problem, thanks to crazyinsomniac and tilly.

And this is incidentally my first post to Meditations and my 100th node (my first question to SOPW for the 200th node)!

<kbd>--
my $OeufMayo = new PerlMonger::Paris({http => 'paris.mongueurs.net'});</kbd>

[tilly]

Who will be using this module?

What will they be using it for?

If you will be tossing new Perl people at the API who have never used the original, then you should definitely create as natural an API as you can.

If you will be tossing people who are used to the old implementation of the API at the new, then there are good reasons to stick, at least in spirit, to the old.

If you are going to spend a lot of time translating code from one language into another, making the correspondence fairly direct is probably a good idea.

And you can always create a Perlish wrapper around something that you don't want to personally use.

All that said, your actual suggestions for what to do with the API seem quite reasonable to me. What I would suggest is that you should create the smallest API that is convenient at the moment, and then start on the real work, adding things as they come up. Probably your length method would never happen. Your error mode probably will. And for things that are not very clear-cut, you will probably find a practical balance between what you need and what you can leave out...