refdb-devel — List for RefDB developers

[Refdb-devel] subversion rulez

[Markus H. <mar...@mh...>]

Hi,

I'd just like to let you know that I've moved all modules from CVS
over to subversion. I'll switch off the CVS access through the project
page, but you'll still be able to access the repository with a CVS
client. However, future development will be reflected only in the
subversion repository.

The repository layout follows the suggestions of the subversion
manual, i.e. each CVS module went into a subdirectory, which in turn
contains a trunk/ subdirectory. Branches and tags will be added to
branches/ and tags/ subdirectories as needed. Checkins will be sent to
ref...@li..., just like the CVS checkins previously.

As for the refdb module I've tossed HEAD and moved the stable branch
to trunk/. This fixes the odd situation that the main development
happened in a branch for more than a year.

I'll update the repository access info on the web page shortly. For
now you may click on the "subversion" menu on the SF project page and
follow the instructions.

regards,
Markus

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

Re: [Refdb-devel] Re: bib2ris spaces in author/editor names

[Markus H. <mar...@mh...>]

Hi Damien,

Damien Jade Duff writes:
 > > I'm still contemplating. It seems more practical to associate the contact info
 > > with an author rather than with a reference, but what if an author moves (which
 > > isn't that rare, believe me :-( ). We'd need another table that holds all
 > > contacts for a particular author and store the information which contact
 > > applies in the reference.
 > > 
 > > 
 > 
 > Gosh, it seems complicated. Not really the kind of sophistication you'd 
 > expect in a reference database really.
 > 
 > Optimally you'd want to chuck it into your contact database, whatever 
 > that is, and throw a link into your reference author I suppose, but now 
 > we're talking 3rd party interfaces... now we're talking crazy talk.
 > 

I just recalled that the contact information given in a reference is
not always associated with the first author of a paper. This makes it
impossible to store the contact info with the author name, as
electronic references do not record which author the contact info
belongs to. The contact info has to stay with the reference, just as
it has done so far.

regards,
Markus

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

Re: [Refdb-devel] Re: bib2ris spaces in author/editor names

[Damien J. D. <D.J...@cs...>]

> 
>>Incidentally, does your planned extension to RIS have a place to put
>>author contact details?
>>
> 
> 
> I'm still contemplating. It seems more practical to associate the contact info
> with an author rather than with a reference, but what if an author moves (which
> isn't that rare, believe me :-( ). We'd need another table that holds all
> contacts for a particular author and store the information which contact
> applies in the reference.
> 
> 

Gosh, it seems complicated. Not really the kind of sophistication you'd 
expect in a reference database really.

Optimally you'd want to chuck it into your contact database, whatever 
that is, and throw a link into your reference author I suppose, but now 
we're talking 3rd party interfaces... now we're talking crazy talk.

I'd leave it out if I were you!

Peace
Damien

[Refdb-devel] Re: bib2ris spaces in author/editor names

[Markus H. <mar...@mh...>]

Hi Damien,

Damien Jade Duff <D.J...@cs...> was heard to say:

> becomes
>
>    AU  - Koza,JohnR.
>    AU  - Streeter,MatthewJ.
>    AU  - Keane,MartinA.
>
> I have tested a fix and it seems to work. I wonder if you would give it
> some oversight and update bib2ris.c for me.
>
> 00004:  $Id: bib2ris.c,v 1.13.2.2 2005/07/29 21:15:34 mhoenicka Exp $
>
> ...
>
> 01326: /*** <djd 20060412> */
> 01327:      if(j < ptr_partlist->part_len[BTN_FIRST]){
> 01328:		if (navail >= 1) {
> 01329:		  strcat(namestring, " ");
> 01330:		  navail--;
> 01331:		}
> 01332:		else {
> 01333:		  goto haveall;
> 01334:		}
> 01335:      }
> 01336: /*** </djd 20060412> */
>

I'll give it a try and update bib2ris.c asap.

> Incidentally, does your planned extension to RIS have a place to put
> author contact details?
>

I'm still contemplating. It seems more practical to associate the contact info
with an author rather than with a reference, but what if an author moves (which
isn't that rare, believe me :-( ). We'd need another table that holds all
contacts for a particular author and store the information which contact
applies in the reference.

> Also, how easy would it be for me to give bib2ris the ability to convert
> abstract and keyword information? (I believe these become N2 and KW
> fields in RIS)

It should be extremely easy (although I haven't tested this in ages). Simply add
something like:

nsf_abstract  N2
nsf_keyword  KW

to your ~/.bib2risrc, assuming that you use "ABSTRACT" and "KEYWORD" in your
bibtex data to denote abstracts and keywords, respectively. See also:

http://refdb.sourceforge.net/manual/sect-bibtoris.html

for some additional hints.

regards,
Markus

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

[Refdb-devel] bib2ris spaces in author/editor names

[Damien J. D. <D.J...@cs...>]

Dear Markus

bib2ris is rather neat isn't it? One thing: at present it does not put 
spaces between names in the author field, so that

   author = "John R. Koza and Matthew J. Streeter and Martin A. Keane",

becomes

   AU  - Koza,JohnR.
   AU  - Streeter,MatthewJ.
   AU  - Keane,MartinA.

I have tested a fix and it seems to work. I wonder if you would give it 
some oversight and update bib2ris.c for me.

00004:  $Id: bib2ris.c,v 1.13.2.2 2005/07/29 21:15:34 mhoenicka Exp $

...

01326: /*** <djd 20060412> */
01327:      if(j < ptr_partlist->part_len[BTN_FIRST]){
01328:		if (navail >= 1) {
01329:		  strcat(namestring, " ");
01330:		  navail--;
01331:		}
01332:		else {
01333:		  goto haveall;
01334:		}
01335:      }
01336: /*** </djd 20060412> */

Incidentally, does your planned extension to RIS have a place to put 
author contact details?

Also, how easy would it be for me to give bib2ris the ability to convert 
abstract and keyword information? (I believe these become N2 and KW 
fields in RIS)

Thanks for your time
And regards
Damien Jade Duff

[Refdb-devel] Two questions

[Markus H. <mar...@mh...>]

[I've cc'ed the list for the archives. Please try to keep stuff like
this on-list]

Sebastian Hoehn writes:
 > when adding references from a ris file (the example file in the dist), I
 > get a  "406 citation key" error message. How do I handle this in the
 > protocol? The current c client works for this, but my ruby binding does
 > not. I checked the perl code and my ruby does not differ from that code.
 > Does it possibly have something to do with the "timeout while writing"
 > message the server prints? Is it a mysql issue?
 > 

The error in the ruby lib must be further down, as the 406 is a
purely informational message. It is supposed to print the newly
assigned reference ID and the citation key. The "timeout while
writing" message is usually caused if the client and the server
implementations are out of sync, i.e. the server tries to write but
the client isn't listening.
 > 
 > If I add a user it is not entered into the t_user table of the database.
 > Is this a bug or a feature?
 > 

The adduser command is supposed to grant access rights to the required
databases. It is not intended to fill the t_user table. This table
will automatically contain the user name as soon as she adds notes or
references. The user is also supposed to disappear when the last note
or reference owned by that user is deleted from the database.

regards,
Markus

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

[Refdb-devel] Solution for the refdb webapp architecture

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

Hi,

I guess I found an appropriate solution how I can connect a rails webapp
to the refdb server.

I need to write a custom activerecord database adapter. I guess this is
a rather good and maintainable approach. If the server protocols change
the bindings and this adapter must be changed. Otherwise the webapp can
work with a merely virtual datastructure that is simulated by the
connection adapter.

I will see tomorrow how this might work.

Bye,

Sebastian


--=20
Sebastian H=F6hn                    <ho...@ii...>
Institut f=FCr Informatik und Gesellschaft, Abteilung Telematik
Universit=E4t Freiburg                Telefon: +49 761 203 4950
Friedrichstra=DFe 50, D-79098 Freiburg  Fax: -4929,  Sek: -4964
-----  IIG im WWW: http://www.telematik.uni-freiburg.de -----

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

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

[Bruce D'A. <bd...@gm...>]

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.

>> 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."

> - 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.).

When you remove the requirement that all data must fit in a level 
model, then you offer more flexibility: horizontal relations such as a 
translation to an original, a speech presented at some event, etc.

Bruce

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

[Bruce D'A. <bru...@Op...>]

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.

>> 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."

> - 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.).

When you remove the requirement that all data must fit in a level 
model, then you offer more flexibility: horizontal relations such as a 
translation to an original, a speech presented at some event, etc.

Bruce

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

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

I guess I will stick to the c client then for the interface. I just
thought using ruby on rails great out of the box database support could
be of great help for my implementation. But you are right with the data
processing that is done despite the simple SQL data access.

Then these projects will never get out of sync. I nevertheless think
about a different way of integrating all that behind a soap interface,
perhaps by calling your C procedures directly, then I do not need to
make any changes even if the protocol changes.


Markus Hoenicka wrote:
> 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?
>   
This is with the C Client. The note I've sent was the example from the
sources.

I do not have the time right now to further investigate this, perhaps I
can solve this by myself.

Regards,

Sebastian

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

[Markus H. <mar...@mh...>]

Sebastian Hoehn <seb...@ii...> 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
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

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

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

Markus Hoenicka wrote:
> Hi,
>
> Sebastian Hoehn writes:
>  > I have an account on sourceforge: yhirmikq
>  > 
>
> I should have asked in the first place: would you prefer to develop
> your stuff as a part of the RefDB project, or would you like to start
> an independent SourceForge project? Either way is fine with me, just let
> me know.
>   
It is a good idea to start a new project, so that I can do some
additional stuff ;-)

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.

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 see the disadvantage not too bad, because the code exists and can be
integrated in the project as is.

I am glad to hear your opinion on the topic.

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


> My test script runs ok, including adding, retrieving, and deleting
> notes. Would you mind sharing some more information about this
> problem? What do the notes look like? What queries do you run? What is
> the context in the log file (i.e. starting from the getnote command)?
>   
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 am currently rewriting and updating the bindings, they are rather out
>  > of date :-(
>  > 
>
> Yes, this is very likely. Diwaker mentioned that his code was lying
> around for half a year before he donated it, and that's also a while
> ago. Hope it's not too much hassle to update the stuff.
>   
It is alright, because I have the great perl module and I can stick with
that if the protocols of Diwaker are out of date. The code snippets
Diwaker provided are working great. So this is just a resembling of the
current sources.

Regards,

Sebastian

[Refdb-devel] Once more the ruby bindings

[Markus H. <mar...@mh...>]

Hi,

Sebastian Hoehn writes:
 > I have an account on sourceforge: yhirmikq
 > 

I should have asked in the first place: would you prefer to develop
your stuff as a part of the RefDB project, or would you like to start
an independent SourceForge project? Either way is fine with me, just let
me know.

 > Is it a known issue or just a problem with my configuration, that notes
 > do not work with the current release?
 > 
 > A snippet from the log reveals the error:
 > 
 > AND  ORDER BY t_note.note_id
 > 1064: You have an error in your SQL syntax; check the manual that
 > corresponds to your MySQL server version for the right syntax to use
 > near 'ORDER BY t_note.note_id' at line 1
 > 
 > There is the search string missing the sql command. Is this working for you?
 > 

My test script runs ok, including adding, retrieving, and deleting
notes. Would you mind sharing some more information about this
problem? What do the notes look like? What queries do you run? What is
the context in the log file (i.e. starting from the getnote command)?

 > 
 > I am currently rewriting and updating the bindings, they are rather out
 > of date :-(
 > 

Yes, this is very likely. Diwaker mentioned that his code was lying
around for half a year before he donated it, and that's also a while
ago. Hope it's not too much hassle to update the stuff.

regards,
Markus

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

[Refdb-devel] Once more the ruby bindings

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

Hi,

I have an account on sourceforge: yhirmikq

Is it a known issue or just a problem with my configuration, that notes
do not work with the current release?

A snippet from the log reveals the error:

AND  ORDER BY t_note.note_id
1064: You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'ORDER BY t_note.note_id' at line 1

There is the search string missing the sql command. Is this working for you?


I am currently rewriting and updating the bindings, they are rather out
of date :-(


Greetings,

Sebastian

-- 
Sebastian Höhn                    <ho...@ii...>
Institut für Informatik und Gesellschaft, Abteilung Telematik
Universität Freiburg                Telefon: +49 761 203 4950
Friedrichstraße 50, D-79098 Freiburg  Fax: -4929,  Sek: -4964
-----  IIG im WWW: http://www.telematik.uni-freiburg.de -----

Re: [Refdb-devel] Re: [Refdb-users] CVS vs. Subversion

[Markus H. <mar...@mh...>]

"Michael(tm) Smith" <sm...@si...> was heard to say:

> Their estimate appears to be that they'll have the CVS service
> available again late Tuesday night or early Wednesday morning.
>

Thanks, it's good to have an estimate.

> The description of the "single point of failure" architecture of
> the CVS service doesn't inspire a lot of confidence in the
> long-term stability of the service. Even before this outage, it
> has been pretty spotty all along anyway -- inaccessible
> intermittently for short periods (and relatively long ones too).
>

I noticed that too. This was one of the most annoying problems of SF so far.

> Anyway, it definitely provides some additional incentive to move
> to their Subversion service instead. Some wags have even suggested
> that the outage was carefully planned to scare project admins away
> from the CVS service and over to the Subversion service (because
> the CVS service is a drain on support resources and they want to
> minimize the number of projects using it). I only wish I thought
> they were quite that smart.
>

Actually I figured that too, but I thought I was just paranoid.

Thanks
Markus


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

Re: [Refdb-devel] Re: [Refdb-users] CVS vs. Subversion

[Michael(tm) S. <sm...@si...>]

Markus Hoenicka <mar...@mh...> writes:

> I gather from this feedback that no one has to stick with CVS. I'll go
> ahead and migrate the CVS repository to Subversion in the near future.
>=20
> Before I do this, I'd like to clean up the repository a bit. Most
> important, I'd like to fold back the stable branch to the trunk as the
> latter has turned out to be sort of a dead end. But in order to do
> this cleanup, and in order to check my local changes I'll have to wait
> until the SourceForge CVS service online again. I'll let you know when
> the migration is done.

Note that SF has a "Site Status" page that they don't do a very
good job of advertising. There's a "Recent Updates" section on
that page that gives details about the CVS outage -

  http://sourceforge.net/docs/A04/#section1

Their estimate appears to be that they'll have the CVS service
available again late Tuesday night or early Wednesday morning.

The description of the "single point of failure" architecture of
the CVS service doesn't inspire a lot of confidence in the
long-term stability of the service. Even before this outage, it
has been pretty spotty all along anyway -- inaccessible
intermittently for short periods (and relatively long ones too).

Anyway, it definitely provides some additional incentive to move
to their Subversion service instead. Some wags have even suggested
that the outage was carefully planned to scare project admins away
=66rom the CVS service and over to the Subversion service (because
the CVS service is a drain on support resources and they want to
minimize the number of projects using it). I only wish I thought
they were quite that smart.

  --Mike

[Refdb-devel] Re: [Refdb-users] CVS vs. Subversion

[Markus H. <mar...@mh...>]

Hi,

I gather from this feedback that no one has to stick with CVS. I'll go
ahead and migrate the CVS repository to Subversion in the near future.

Before I do this, I'd like to clean up the repository a bit. Most
important, I'd like to fold back the stable branch to the trunk as the
latter has turned out to be sort of a dead end. But in order to do
this cleanup, and in order to check my local changes I'll have to wait
until the SourceForge CVS service online again. I'll let you know when
the migration is done.

regards,
Markus


David Mundie writes:
 > I've used both and think you should immediately switch to Subversion  
 > and never look back.
 > 
 >   - dam
 > 
 > On 2006-Apr-01, at 17:00, Daniel O'Donnell wrote:
 > 
 > > I've never used CVS so I can't compare it to SVN, but I am really  
 > > happy
 > > with SVN which I use all the time.
 > >

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

[Refdb-devel] Re: [Refdb-users] CVS vs. Subversion

[David M. <mu...@an...>]

I've used both and think you should immediately switch to Subversion  
and never look back.

  - dam

On 2006-Apr-01, at 17:00, Daniel O'Donnell wrote:

> I've never used CVS so I can't compare it to SVN, but I am really  
> happy
> with SVN which I use all the time.
>
> -d
>
> On Sat, 2006-01-04 at 22:20 +0200, Markus Hoenicka wrote:
>> Hi,
>>
>> I don't know how many RefDB users ever try to build from CVS. I guess
>> there are some, and this message is relevant to those as well as to
>> all developers.
>>
>> SourceForge has ongoing problems with their CVS servers. This
>> currently prevents me from finishing the next prerelease and from
>> adding a new RefDB application (soon to be announced). The Subversion
>> servers seem to work ok. It is up to the project admin (read: up to
>> me) to migrate the CVS repository to Subversion. I'm not in a  
>> hurry to
>> do this, and I'd like to get your opinions first. Would the move to
>> Subversion break anything? I'm afraid the refdb-cvs scripts would  
>> need
>> an overhaul. Let me know what you think.
>>
>> If you don't know Subversion yet, just go to
>>
>> http://subversion.tigris.org/
>>
>> to read more about this CVS replacement.
>>
>> regards,
>> Markus
>>
>>
> -- 
> Daniel Paul O'Donnell
> Associate Professor and Acting Chair
> Director, Digital Medievalist Project
> <http://www.digitalmedievalist.org/>
> Department of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Canada
>
> Vox +1 403 329-2377
> Fax +1 403 382-7191
>
> :@caedmon/ubuntu
>
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Refdb-users mailing list
> Ref...@li...
> https://lists.sourceforge.net/lists/listinfo/refdb-users

[Refdb-devel] Re: [Refdb-users] CVS vs. Subversion

[Daniel O'D. <dan...@ul...>]

I've never used CVS so I can't compare it to SVN, but I am really happy
with SVN which I use all the time.

-d

On Sat, 2006-01-04 at 22:20 +0200, Markus Hoenicka wrote:
> Hi,
> 
> I don't know how many RefDB users ever try to build from CVS. I guess
> there are some, and this message is relevant to those as well as to
> all developers.
> 
> SourceForge has ongoing problems with their CVS servers. This
> currently prevents me from finishing the next prerelease and from
> adding a new RefDB application (soon to be announced). The Subversion
> servers seem to work ok. It is up to the project admin (read: up to
> me) to migrate the CVS repository to Subversion. I'm not in a hurry to
> do this, and I'd like to get your opinions first. Would the move to
> Subversion break anything? I'm afraid the refdb-cvs scripts would need
> an overhaul. Let me know what you think.
> 
> If you don't know Subversion yet, just go to
> 
> http://subversion.tigris.org/
> 
> to read more about this CVS replacement.
> 
> regards,
> Markus
> 
> 
-- 
Daniel Paul O'Donnell
Associate Professor and Acting Chair
Director, Digital Medievalist Project
<http://www.digitalmedievalist.org/>
Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Canada

Vox +1 403 329-2377
Fax +1 403 382-7191

:@caedmon/ubuntu

[Refdb-devel] CVS vs. Subversion

[Markus H. <mar...@mh...>]

Hi,

I don't know how many RefDB users ever try to build from CVS. I guess
there are some, and this message is relevant to those as well as to
all developers.

SourceForge has ongoing problems with their CVS servers. This
currently prevents me from finishing the next prerelease and from
adding a new RefDB application (soon to be announced). The Subversion
servers seem to work ok. It is up to the project admin (read: up to
me) to migrate the CVS repository to Subversion. I'm not in a hurry to
do this, and I'd like to get your opinions first. Would the move to
Subversion break anything? I'm afraid the refdb-cvs scripts would need
an overhaul. Let me know what you think.

If you don't know Subversion yet, just go to

http://subversion.tigris.org/

to read more about this CVS replacement.

regards,
Markus


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

[Refdb-devel] Fwd: dependencies of vim-docbk-xml-refdb

[Markus H. <mar...@mh...>]

David, any chance to fix this in a reasonable timeframe?

----- Weitergeleitete Nachricht von Michael Wild <mw...@st...> -----
    Datum: Fri, 27 Jan 2006 09:43:49 +0100
    Von: Michael Wild <mw...@st...>
Antwort an: Michael Wild <mw...@st...>
 Betreff: dependencies of vim-docbk-xml-refdb
      An: mho...@us...

Hi

I tried installing vim-docbk-xml-refdb on my debian system.
Unfortunately the dependencies seem to be broken: the package requires
xml-commons-resolver to be installed, but this package has been removed
and replaced by libxml-commons-resolver1.1-java (as much as I gathered
from the mailing lists).



Michael**

----- Ende der weitergeleiteten Nachricht -----


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

Re: [Refdb-devel] Example Out of Date

[Markus H. <mar...@mh...>]

That's correct. I'll fix this for the next release.

regards,
Markus

David Mundie <mu...@an...> was heard to say:

> The testrefs.xml file in the examples folder needs to be updated to
> the latest risx DTD - it still has a url element, and is missing the
> type attribute on titles.
>
>   - dam
>



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

[Refdb-devel] Example Out of Date

[David M. <mu...@an...>]

The testrefs.xml file in the examples folder needs to be updated to  
the latest risx DTD - it still has a url element, and is missing the  
type attribute on titles.

  - dam

Re: [Refdb-devel] backend-bibtex.c + runbib

[Damien J. D. <D.J...@cs...>]

 >  >        strcmp(type, "RPRT") == 0 || strcmp(type, "CONF") == 0 )
 >  >          {
 >  > /*djd 20060101 It may be that we want to put "HEAR" in here too???*/
 >  >
 >
 > Is "HEAR" really treated like a
 > book rather than like an article?
 >

Gidday,

I think you are probably right - in the examples I picked up from the
APA guidelines just now at your instigation, no collection title is
supplied. I only sugested the change because it was, like CONF, treated
as @PROCEEDINGS and my change to the logic for determining @TYPE changed
@PROCEEDINGS to @INPROCEEDINGS for both CONF and HEAR.

(@PROCEEDINGS is used to reference the whole show, @INPROCEEDINGS for a
part of the show - like a paper in a conference)

So the change I made to @TYPE is wrong for HEAR.
It should be instead...

else if (strcmp(type, "CONF") == 0 ) {
       strcat(*(ptr_rendinfo->ptr_ref), "@INPROCEEDINGS{ ");
}
else if ( strcmp(type, "HEAR") == 0) {
       strcat(*(ptr_rendinfo->ptr_ref), "@PROCEEDINGS{ ");
}

 >
 > You know bibtex far better than me so I assume this change is correct.
 >

Yes, you can trust me... ;-)
To be honest, I'm learning bibtex while I learn refdb. But, as you
suggest, it is the practical experience of actually using the package
that is most important.

Thanks again for your support.

Peace
Damien