Trook unable to fetch Calibre 0.7.1 opds catalogs?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install calibre 0.7.1 on myserver.mydomain.com
2. Launch trook and "open" http://myserver.mydomain.com:8080/opds
3.

What is the expected output? What do you see instead?
-Should see browsing by author, title, etc as one does when specifying 
http://myserver.mydomain.com:8080/opds with icons to descend into those levels.
-Instead see list of browse topics but no icons
-Kovid added the /opds sub-page in Calibre v0.7.0 to support NON-epub books via 
opds/trook (since /stanza will not support .PDF etc) so I'm not sure if trook 
needs a tweak to understand this

What version of the product are you using? On what operating system?
-Trook v68 on 1.3 softroot

Do you have any output from "adb logcat" that contains stack traces or logs
that might be related?
-No

Original issue reported on code.google.com by richards...@gmail.com on 11 Jun 2010 at 3:30

[GoogleCodeExporter]

It's worse than I thought - the /stanza page behaves identically - which means 
that Trook v68 doesn't actually work with Calibre 0.7.1.  Trook appears to have 
cached my /stanza page so things appeared to work there until I tried to get 
new content.

Original comment by richards...@gmail.com on 11 Jun 2010 at 3:32

[GoogleCodeExporter]

After some digging around, I *believe* the problem lies in the fact that 
Caliber 0.7.x includes more complex links:

0.6.5x returned:
    <link type="application/atom+xml" href="/stanza/?sortby=byauthor"/>
where 0.7.x returns:
    <link href="/stanza/navcatalog/4e617574686f7273" type="application/atom+xml;type=feed;profile=opds-catalog"/>

When I look at Trook's AtomFeedParser.java it appears the function 
isStanzaSearchLink() checks the link type for *EQUALITY* with 
"application/atom+xml" which was true in Stanza 0.6.5x but not in 0.7.x?

It also appears that Stanza reverses the order of the href and type tokens in 
the link statement, so perhaps Trook only accepts them in that order?

I'm not currently able to rebuild Trook to experiment, so please advise.

Original comment by richards...@gmail.com on 14 Jun 2010 at 7:03

[GoogleCodeExporter]

Confirmed by hacking Calibre 0.7.2 source - Trook works fine when the type tag 
is returned as *only* "application/atom+xml" which makes sense given 
isStanzaSearchLink() does the following comparison:
       "application/atom+xml".equals(li.getAttribute("type"))
if that were .contains or something similar, I think it would work for both 
0.6.xx and 0.7.xx Calibre versions.

Could someone update Trook with this change please?

Original comment by richards...@gmail.com on 15 Jun 2010 at 2:57

[GoogleCodeExporter]

Just FYI I too am having the issue.  

Original comment by dppip...@gmail.com on 26 Jun 2010 at 5:59

[GoogleCodeExporter]

I've put a filter in between my calibre server and my nook that parses the 
offending text out of the calibre feed so my stuff works but as the calibre 
feed is valid it sure would be nice if this could be addressed in trook.

Original comment by craftycoder on 29 Jun 2010 at 8:49

[GoogleCodeExporter]

I get compile errors when I try to rebuild Trook from the SVN source, so *I* 
have not been able build a fixed version :(

Original comment by richards...@gmail.com on 29 Jun 2010 at 9:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I too have modified Trook both with respect to its issues with parsing 
Atom-type links with additional type information, and with respect to another 
issue it has with Stanza searches, at least in interaction with Calibre.  I'm 
attaching individual diffs relative to r74 for both.

Original comment by mgoetze2...@gmail.com on 15 Jul 2010 at 9:01

Attachments:

• nookapps@r74--fix_parsing_of_opds_atom_links_with_additional_type_information.diff
• nookapps@r74--fix_calibre_stanza_searches.diff

[GoogleCodeExporter]

In addition to my previous comment: Calibre may need a fix or two of its own to 
its server code to avoid errors happening there to get this working.  I can 
make these available as well.

Original comment by mgoetze2...@gmail.com on 15 Jul 2010 at 11:23

[GoogleCodeExporter]

I solved both these problems as well, but I took a different approach with the 
search fix. I should install SVN into my Eclispe so I can generate these diff 
files.

Original comment by craftycoder on 15 Jul 2010 at 11:26

[GoogleCodeExporter]

Are you confident that the code:

type.replaceFirst(";.*", "");

will always work as expected? What if feed looked like this?

<link href="/opds/navcatalog/4f7469746c65" 
type="type=feed;profile=opds-catalog;application/atom+xml"/> 

Original comment by craftycoder on 15 Jul 2010 at 11:37

[GoogleCodeExporter]

Off-topic, but personally, I use git (via git-svn) on the command-line for this 
type of "hacking" a project because this makes it easy to keep one's 
modifications on top of the trunk, streamline the local history, and isolate 
commits (e.g. for posting diffs) when required. Recommended!

Original comment by mgoetze2...@gmail.com on 15 Jul 2010 at 11:41

[GoogleCodeExporter]

Re #11: No, you're obviously right if that is a legal way of specifying the 
type.  Also, I've only tested this with Calibre, so it may very well fail with 
all manner of other OPDS systems.  Alternative patch attached.

Once at it, there's also the matter of case-sensitive string comparisons Trook 
does all over the place.  I'm pretty sure MIME types, i.a., could as well use 
uppercase letters, which would have these comparisons fail.  And there are 
quite a few places where null isn't properly checked for in the code, but where 
to start?

Original comment by mgoetze2...@gmail.com on 15 Jul 2010 at 12:01

Attachments:

• nookapps@r74--fix_parsing_of_opds_atom_links_with_additional_type_information_v2.diff

[GoogleCodeExporter]

Does anybody know what happened to Kb Sriram ? I've lost track of him a few 
months ago and he's not answering my emails...

Original comment by dpier...@gmail.com on 31 Aug 2010 at 2:56