refdb-devel Mailing List for RefDB (Page 4)
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-devel — List for RefDB developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2003 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(4) |
Jul
(11) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(174) |
| 2004 |
Jan
(10) |
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(25) |
Oct
(18) |
Nov
(16) |
Dec
(19) |
| 2006 |
Jan
(6) |
Feb
|
Mar
|
Apr
(21) |
May
(9) |
Jun
(5) |
Jul
(51) |
Aug
(89) |
Sep
(42) |
Oct
(19) |
Nov
(47) |
Dec
(4) |
| 2007 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(5) |
Oct
|
Nov
(7) |
Dec
(4) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(14) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
(21) |
Mar
(8) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(14) |
Nov
|
Dec
|
| 2010 |
Jan
(18) |
Feb
(5) |
Mar
|
Apr
|
May
(4) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2009-04-29 21:28:14
|
Feature Requests item #2783033, was opened at 2009-04-28 19:42 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385994&aid=2783033&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None >Status: Closed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: enigma encryption optional Initial Comment: Please make encryption of the password optional. Rationale: Often (if not mostly), RefDB is connected from localhost only, therefore, there is no transmission over an unstrusted network. Since the algorithm is non-standard, you have to implement it for every client implementation. Unless of course you use eenc which is an unnecessary dependency for your client package. If it wasn't for the sake of compatibility, I'd even request to remove it entirely: Tunneling through ssh or using openssl is the way to go, and easy enough. ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-04-29 23:28 Message: I've added a command line switch (-x) and configure options (no_encrypt for the clients, no_decrypt for the server) to use plain-text passwords. The default is still to use encrypted passwords, but if you know what you're doing you can now switch off encryption. Needless to say, both server and clients must use the same setting in order to cooperate properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385994&aid=2783033&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-04-28 17:42:31
|
Feature Requests item #2783033, was opened at 2009-04-28 19:42 Message generated for change (Tracker Item Submitted) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385994&aid=2783033&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: enigma encryption optional Initial Comment: Please make encryption of the password optional. Rationale: Often (if not mostly), RefDB is connected from localhost only, therefore, there is no transmission over an unstrusted network. Since the algorithm is non-standard, you have to implement it for every client implementation. Unless of course you use eenc which is an unnecessary dependency for your client package. If it wasn't for the sake of compatibility, I'd even request to remove it entirely: Tunneling through ssh or using openssl is the way to go, and easy enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385994&aid=2783033&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-04-25 01:09:22
|
Bugs item #2780939, was opened at 2009-04-25 03:09 Message generated for change (Tracker Item Submitted) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2780939&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Docs: options for second stage in protocol wrong Initial Comment: (Due to the transition to another tracker on Sourceforge, I cannot comment on issue 2623944 anymore, so I open a new one.) See <http://refdb.sourceforge.net/manual/ch23s02.html>. The options still don't seem quite right. 1) The explanation of -S contradicts with its "replaceable". 2) Does "-S" mean sorting with getref? 3) How do I get only the IDs with getref? With "-s ID"? 4) "-t" is called "output-type" rather than "ref_format" in <http://refdb.sourceforge.net/manual/re11.html#app-c-command-getref>. This should be adjusted in my opinion. Adding 'Available are "scrn", "ris", "risx", "html", "xhtml", "db31", "db31x", "db50x, "teix", "tei5x", "mods", and "bibtex".' would make it even clearer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2780939&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-04-17 20:28:51
|
Bugs item #2769590, was opened at 2009-04-17 00:59 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2769590&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: <link> disappears Initial Comment: If I add the following dataset to RefDB, <entry citekey="Doe2008" type="JOUR"> <part> <title>An interesting article</title> <author> <lastname>Doe</lastname> <firstname>John</firstname> </author> </part> <publication> <pubinfo> <!--userdef type="1">PUBLIC</userdef--> <link type="pdf">PUBLIC</link> </pubinfo> </publication> </entry> the <link> element disappears from the database. If I uncomment the <userdef>, it does not disappear. ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-04-17 22:28 Message: The link element is correctly added to the database, but the risx backend contained a bug which dropped the link element from the pubinfo element if the latter did not contain any other elements. Hence the non-disappearance if you add a userdef (or any other pubinfo child but link). This bug has been fixed in svn. Please see also the discussion on the mailing list about a related link bug which I fixed while I was at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2769590&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-04-16 22:59:44
|
Bugs item #2769590, was opened at 2009-04-17 00:59 Message generated for change (Tracker Item Submitted) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2769590&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: <link> disappears Initial Comment: If I add the following dataset to RefDB, <entry citekey="Doe2008" type="JOUR"> <part> <title>An interesting article</title> <author> <lastname>Doe</lastname> <firstname>John</firstname> </author> </part> <publication> <pubinfo> <!--userdef type="1">PUBLIC</userdef--> <link type="pdf">PUBLIC</link> </pubinfo> </publication> </entry> the <link> element disappears from the database. If I uncomment the <userdef>, it does not disappear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2769590&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 21:46:03
|
Bugs item #2687681, was opened at 2009-03-15 14:58 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2687681&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Two issues with xnote DTD Initial Comment: Two minor problems regarding the extended notes DTD: In the DTD, the <content> element is mandatory. However, if I request the reference lists of a user (which are organised as extended notes), there is no <content>, just <title> and <link>. The second problem are the links from the documentation to the xnote DTD. It's <http://refdb.sourceforge.net/xnote/>, but the docs refer to <http://refdb.sourceforge.net/dtd/xnote/xnote.dtd>. ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-03-16 22:45 Message: It now seems pretty obvious to me that the content element is not required. I've changed the DTD accordingly by making the content element optional. The link problem is apparently a consequence of how Firefox handles DTD files. The link is correct, and the DTD file is there, but Firefox (and probably other browsers) do not show this file and try to do something special with it. Seems like its more useful to link to the docs instead of to the DTD file. I've changed all occurrences in the doc sources accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2687681&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-15 14:00:00
|
Bugs item #2687681, was opened at 2009-03-15 14:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2687681&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Two issues with xnote DTD Initial Comment: Two minor problems regarding the extended notes DTD: In the DTD, the <content> element is mandatory. However, if I request the reference lists of a user (which are organised as extended notes), there is no <content>, just <title> and <link>. The second problem are the links from the documentation to the xnote DTD. It's <http://refdb.sourceforge.net/xnote/>, but the docs refer to <http://refdb.sourceforge.net/dtd/xnote/xnote.dtd>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2687681&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 20:20:51
|
Bugs item #2623944, was opened at 2009-02-21 14:11 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2623944&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Docs: options for second stage in protocol wrong Initial Comment: See <http://refdb.sourceforge.net/manual/ch23s02.html>. The options don't seem to be correct. In particular, I found out that a lowercase "-s" must be used to set the bibliography style. ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-03-01 21:20 Message: Agreed :-/ However, checkref uses "-s" to request additional fields in the xhtml output. This has been corrected in revision 662. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-03-01 10:30 Message: As far as I can see, "-s" doesn't denote input format for addref etc., but "-A". ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-22 02:05 Message: The usage of "-s" with getbib was indeed missing from the docs. I've updated the info in svn. Feel free to reopen this bug if you run into other incorrect or incomplete options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2623944&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 20:16:17
|
Bugs item #2651276, was opened at 2009-03-01 10:33 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2651276&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Client/server Docs: updateref is missing Initial Comment: Apparently addref was split in addref and updateref, the latter being unmentioned so far in the docs. I think that this also affects the "-p" option which doesn't seem to have a numeric parameter anymore (according to my re-engineering ;-). ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-03-01 21:15 Message: I've added updateref and checkref to the addref description as all commands use the same protocol and the same options. The description of the "-p" option is wrong indeed, reflecting its older usage in the days of yore. It is now used without a parameter and passes the "-P" command line switch to the server, indicating that only the personal information should be updated. Fixes are available in revision 661. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2651276&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 09:33:06
|
Bugs item #2651276, was opened at 2009-03-01 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2651276&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Client/server Docs: updateref is missing Initial Comment: Apparently addref was split in addref and updateref, the latter being unmentioned so far in the docs. I think that this also affects the "-p" option which doesn't seem to have a numeric parameter anymore (according to my re-engineering ;-). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2651276&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 09:30:53
|
Bugs item #2623944, was opened at 2009-02-21 14:11 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2623944&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: Docs: options for second stage in protocol wrong Initial Comment: See <http://refdb.sourceforge.net/manual/ch23s02.html>. The options don't seem to be correct. In particular, I found out that a lowercase "-s" must be used to set the bibliography style. ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-03-01 10:30 Message: As far as I can see, "-s" doesn't denote input format for addref etc., but "-A". ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-22 02:05 Message: The usage of "-s" with getbib was indeed missing from the docs. I've updated the info in svn. Feel free to reopen this bug if you run into other incorrect or incomplete options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2623944&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 09:12:40
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-03-01 10:12 Message: Sorry, I've not the slightest ides why Sourceforge reopened this issue implicitly. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-03-01 10:07 Message: It works now with "-E utf-8", thank you! ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:57 Message: I've commited the fix in refdbdgetref.c and a similar one in refdbdnote.c, available in revision 660. Please give it a try if time permits. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:11 Message: I believe the "utf8" in your risx output is a consequence of a problem we've discussed a few days ago. PostgreSQL changed the encoding name from UNICODE to UTF8. Older versions of the pgsql libdbi driver do not recognize this encoding name and pass it unaltered instead of translating it to the IANA name, hoping that the application using libdbi can make sense of it. Revision 1.62 of the pgsql driver takes care of this problem, so you'd have to upgrade libdbi-drivers to get rid of this problem. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 15:10 Message: I must correct myself: I didn't see that refdbc passes utf8, I simply assumed that it does so (possibly implicitly) because it's what comes back from the server, and because my client worked with utf8, too. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-03-01 09:08:20
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Settings changed) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-03-01 10:07 Message: It works now with "-E utf-8", thank you! ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:57 Message: I've commited the fix in refdbdgetref.c and a similar one in refdbdnote.c, available in revision 660. Please give it a try if time permits. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:11 Message: I believe the "utf8" in your risx output is a consequence of a problem we've discussed a few days ago. PostgreSQL changed the encoding name from UNICODE to UTF8. Older versions of the pgsql libdbi driver do not recognize this encoding name and pass it unaltered instead of translating it to the IANA name, hoping that the application using libdbi can make sense of it. Revision 1.62 of the pgsql driver takes care of this problem, so you'd have to upgrade libdbi-drivers to get rid of this problem. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 15:10 Message: I must correct myself: I didn't see that refdbc passes utf8, I simply assumed that it does so (possibly implicitly) because it's what comes back from the server, and because my client worked with utf8, too. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 19:57:44
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:57 Message: I've commited the fix in refdbdgetref.c and a similar one in refdbdnote.c, available in revision 660. Please give it a try if time permits. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:11 Message: I believe the "utf8" in your risx output is a consequence of a problem we've discussed a few days ago. PostgreSQL changed the encoding name from UNICODE to UTF8. Older versions of the pgsql libdbi driver do not recognize this encoding name and pass it unaltered instead of translating it to the IANA name, hoping that the application using libdbi can make sense of it. Revision 1.62 of the pgsql driver takes care of this problem, so you'd have to upgrade libdbi-drivers to get rid of this problem. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 15:10 Message: I must correct myself: I didn't see that refdbc passes utf8, I simply assumed that it does so (possibly implicitly) because it's what comes back from the server, and because my client worked with utf8, too. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 19:50:56
|
Bugs item #2647990, was opened at 2009-02-28 08:12 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2647990&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: <title> shouldn't have "type" required Initial Comment: In the RISX DTD, the "type" attribute is required for <title>, however instead, it should be "full" as the default or #IMPLIED. ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:50 Message: I've changed the DTD to use "full" as the default. Remember that RefDB revisions prior to 659 cannot import datasets properly which include journal/newspaper/magazine titles without a type attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2647990&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 19:11:14
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 20:11 Message: I believe the "utf8" in your risx output is a consequence of a problem we've discussed a few days ago. PostgreSQL changed the encoding name from UNICODE to UTF8. Older versions of the pgsql libdbi driver do not recognize this encoding name and pass it unaltered instead of translating it to the IANA name, hoping that the application using libdbi can make sense of it. Revision 1.62 of the pgsql driver takes care of this problem, so you'd have to upgrade libdbi-drivers to get rid of this problem. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 15:10 Message: I must correct myself: I didn't see that refdbc passes utf8, I simply assumed that it does so (possibly implicitly) because it's what comes back from the server, and because my client worked with utf8, too. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 14:10:52
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-02-28 15:10 Message: I must correct myself: I didn't see that refdbc passes utf8, I simply assumed that it does so (possibly implicitly) because it's what comes back from the server, and because my client worked with utf8, too. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 14:06:03
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-28 15:05 Message: I've also spent some time analyzing this problem. Turns out that the last character (the > in risx output and a CR in ris output) is only missing if refdbd has to do a character encoding transformation. This is why I didn't see this problem in my regular setup. However, requesting the data in any encoding other than the database encoding reproduces this problem. This will be fixed in svn shortly. As to your utf-8 vs. utf8 experiments: refdbc should not pass this string unless you tell it so. RefDB (or rather libdbi) expects encoding names using the IANA names, so utf8 is simply invalid. utf-8 should work ok with refdbc with the svn revisions that I'll check in shortly. I'd appreciate if you could verify the fix with your setup. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 13:41:56
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:38 Message: Supplement: Please don't consider this a workaround because utf8 is not a valid encoding name in XML. Even worse, the parser that I use rejects it. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 13:26:52
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-02-28 14:26 Message: I sniffed the socket communication with Wireshark and compared my client with refdbc. The difference is that I pass "-E utf-8" and refdbc passes "-E utf8". This is then embedded into the XML declaration of the response, so my response becomes one byte too long. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-28 07:12:52
|
Bugs item #2647990, was opened at 2009-02-28 08:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2647990&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: unspecified Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: <title> shouldn't have "type" required Initial Comment: In the RISX DTD, the "type" attribute is required for <title>, however instead, it should be "full" as the default or #IMPLIED. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2647990&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-27 10:10:59
|
Bugs item #2619021, was opened at 2009-02-20 08:48 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2619021&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: "pickref -r" causes premature end of transmission Initial Comment: When sending "pickref -r -l listname" to the server, the server ends the communication immediately after the transmission of the IDs. Despite that, the item is removed from the list. You can see this problem even in refdbc: refdbc: dumpref -d biblio -b wichtig 1 error ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:10 Message: Could you please send a test kit to me, or attach it to this bug report? Please start with a fresh RefDB database, add the minimum number of datasets required to reproduce the bug, and keep a refdbd log with log level set to 7. Also, please check your MySQL or PostgreSQL logs for anything interesting. Please zip or tar all relevant files/snippets for review. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-02-27 10:32 Message: I installed now the SVN version but I still get refdbc: pickref -b wichtig 1 421:'chantal-wichtig' -> REFERENCE:Bld2006 999:1 picked:0 skipped:0 failed refdbc: dumpref -b wichtig 1 error refdbc: ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-22 22:32 Message: Yes, sorry, I used -b instead of -l. I run refdbc 0.9.9-1 built from svn revision 531 refdbd 0.9.9-1 built from svn revision 531 I have not the time to investigate this further at the moment. Maybe in a couple of weeks. A quick look at the diffs revealed nothing spectacular. However, I don't speak C very well. ---------------------------------------------------------------------- Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-22 21:41 Message: I cannot reproduce this problem here using refdbc. If you run into this problem consistently, it may have been fixed unintentionally as there are no hints to such a problem in the cvs logs of refdbdref.c. Which version of RefDB are you using? Sending "pickref -r -l listname" to the server is likely to cause problems because "-l" is not a valid option. Use "-b" instead to pass the list name. If you found "-l" somewhere in the docs, it's a bug and I'd like to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2619021&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-27 10:06:57
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Markus Hoenicka (mhoenicka) Date: 2009-02-27 11:06 Message: I've found no trace of this problem in the svn logs of backend-risx.c. I cannot reproduce it with refdbc, as you've noticed yourself. I'll test this with the Perl module tonight. However, as refdbc does not add anything to the data sent by refdbd, I'd rather suspect a bug in your implementation of the protocol, or a bug in the documentation of the protocol. Looks like a typical off-by-one error. If nothing else helps, I might try to read your code (although I'm not familiar with that language you're using) and see if something jumps at me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-27 09:43:42
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2009-02-27 10:43 Message: Clarification: It happens if you connect though a socket to refdbd but not with refdbc. Each entry is sent as one socket chunk, however, the four NULLs at the end are one character too early: "...</libinfo>\n </entry\x00\x00\x00\x00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
|
From: SourceForge.net <no...@so...> - 2009-02-27 09:36:00
|
Bugs item #2644739, was opened at 2009-02-27 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: refdbd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Bronger (bronger) Assigned to: Markus Hoenicka (mhoenicka) Summary: refdbd yields invalid XML as RISX Initial Comment: Using "getref" with refdb using the RISX format, the output is not valid XML because the <entry> end tags are missing the closing angle bracket: ... <libinfo user="chantal"> <notes>accepted for publication</notes> <reprint status="NOTINFILE"/> </libinfo> </entry </ris> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=385991&aid=2644739&group_id=26091 |
6 messages has been excluded from this view by a project administrator.
