Re: [Refdb-devel] Once more the ruby bindings

[Sebastian H. <seb...@ii...>]

Bruce D'Arcus wrote:
>
> On Apr 11, 2006, at 7:42 AM, Markus Hoenicka wrote:
>
>>> 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.
>
> Yikes. Sebastian, why would you use SOAP?  A RESTful approach like SRU
> or the new unAPI would be much simpler all around.
This is because SOAP comes for "free" with ruby. I just need to write
one class with the adequate functions and register it with the SOAP
server. The server comes with standard ruby. The same is true for the
client I just need to create a proxy object and the rest is
automagically done.

I don't know who said this, but it is true in this discussion:

"The good thing about standards is that there are so many to choose
from" ;-)

I will do a SOAP interface (the main reason: I know how to do it and it
is simple), we can discuss the rest later on.

>>> 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.
>
> Yeah, I was wondering when you were going to say this. The whole point
> of Rails is really the OO-relational mapping. And then you start to
> wonder what you have that is still "RefDB."
I didn't wonder what is still refdb, since we have all the client tools,
that generate bibfiles, integrate into xml editing for emacs and so on.
Perhaps the webapp is just another "view" on the database?

All this stuff is not part of the webapp. I am still not very sure
whether ruby and particularly rails should not access the sql database. 
Ruby can easily interface c code. So why not use the refdb code as a
"library" for doing all the semantic stuff like parsing RIS and scanning
for keywords? So we will not get two projects running out of sync, since
they reuse the same code.

If the database structure changes I need to redo some of the stuff, but
that should not be an issue too big. Since most of the database is
generated by rails, this must be regenerated the fixes that have to be
done should not be too complex. If these changes are too big, I am in
doubt that the protocols and datastructures between the client and
server will stay as they are.
>> - 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.
>
> What changes are you contemplating to the SQL model Markus?
>
> FWIW, I've come to the conclusion that reference data really comes
> down to these primary entities: Reference (anything citable),
> Collection (periodicals, archival collections, series), Event
> (workshops, conferences, etc.), and Contributor (authors, publishers,
> translator, etc.).
I still wonder, how the ris model depends on the sql structure. I like
the db structure of refdb and do not see the necessity to change it. If
extensions are needed that should not break the existing structure.
Furthermore, is it important to be backward compatible since existing
databases should be accessible by future versions of refdb.

Thanks for the good and interesting points in this discussion.


Regards,

Sebastian