Re: Once more the ruby bindings

Sebastian Hoehn <[email protected]> was heard to say:

> It is a good idea to start a new project, so that I can do some
> additional stuff ;-)
>

Fine with me.

> I currently update the existing ruby bindings. That is fine and I hope
> will be finished soon.
> Furthermore I currently think about a SOAP bindings implemented in Ruby
> to access the refdb database. This will deliver a standards compliant
> interface to the server and deserve as a good starting point for future
> interfaces.
>

Sounds cool. What about SRW? I thought implementing an SRW interface using
Indexdata's SimpleServer, but if it is trivial to add this functionality to
your SOAP code you might as well do it.

> Furthermore the ruby on rails webapp will be part of the new project. I
> am still thinking about accessing the database directly from the webapp.
> What is the pros and cons of additionally involving the current c-client
> and server? The same is true for the possible implementation of the soap
> bindings. Are there any advantages of additionally involving that
> server? No matter, the current client and server are great and really
> appreciate the emacs interface, but I wish to establish a central ref
> database here at work and not everybody will be satisfied with that
> interface. So the question is: should the webapp for managing the
> references work directly with the database or is it better to interact
> with the current server?
>
> For two reasons I am in favor of the "direct approach" for the web app:
>
> - We reduce the number of bugs, there are just the webapp and
> mysql/pgsql/sqlite bugs, no server bugs
> - We enhance performance, since all the queries can be executed directly
>
> There certainly is a disadvantage, too:
> - There is no support for ris, risx, bibtex and so on.
>

I went through this a couple of times in the past, but it doesn't hurt to
reiterate the issues here. You should be aware that refdbd does more than just
map RIS lines to database fields, dumping whatever it receives. refdbd has to
take apart some of the data (e.g authors, dates), normalize data (author names,
journal titles, scan data for keywords. If you bypass refdbd,

- you'll have to reimplement this code in Ruby. Instead of avoiding the server
bugs, you'll just add new bugs, increasing the overall number of bugs.
- you may end up with two slightly different implementations. I do get the very
same results on the command line, in refdb-mode, and in any Perl script that
uses the RefDBClient module. If your new code does not use exactly the same
algorithms (including the same bugs), your data will depend on how you add them
to or retrieve them from the database.

- you'll have to change your code whenever I do. I'm just compiling a proposal
how to extend the RIS model to make it easier to implement and understand. This
will require thorough changes to the SQL database schemas. I'm sure that I can
implement these changes without affecting the client-server interface or the
client functions. If you want to access the tables directly, you can dump half
of your code right after you've implemented it. If you go through refdbd,
you'll probably get away with cosmetic fixes in the interface to better support
the new data model. It should be obvious that two implementations maintained by
two different projects will almost always be out of sync.

Taken together, I don't see an advantage that direct table access may provide.
I'd strongly recommend to use Diwaker's code to talk to refdbd instead of to
the database engines. You'll get 90% of the nasty code for free, you'll program
agains a fairly stable interface, and you can concentrate on providing a good
interface instead of reinventing my bugs.

> The new project I will register with sourceforge will be called refdbonrails
>

A cool name is half the fare...

> These are among the issues I dislike with the current server. The
> communication is rather complicated and these errors cannot be
> reproduced. I currently have two refdb servers running for testing the
> ruby bindings and if one fails, the other works ;-)
> >  >

I'd suspect that there is some problem with the ruby code. I did not experience
this kind of problems with either the C clients or the Perl module. Can you
reproduce the problems with one of these clients?

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642