Hi Henrik,
> 1.) This is what each "remote" looks like by way of E/R:
>
> (class +WordCount +Entity)
> (rel article =C2=A0 (+Ref +Number))
> (rel word =C2=A0 =C2=A0 =C2=A0(+Aux +Ref +Number) (article))
> (rel count =C2=A0 =C2=A0 (+Number))
> (rel picoStamp (+Ref +Number))
>
> (dbs =C2=A0
> =C2=A0 (4 +WordCount)
> =C2=A0 (3 (+WordCount word article picoStamp)))
>
I can't see how this works. In the search index I implemented was like
this:
("picolisp" (5 . "file1") (4 . "file2") ...)
("google" (3 . "file1") (2 . "file3") ...)
...
In your schema, I don't see how words are represented.
> The bottleneck lies somewhere else than the actual lookup,
So what is the problem then? ;-)
> search since it returns the maximum 50 where picolisp only returns 8.
Those are very long times considering there are so little results.
> So the bottleneck is not the search itself but rather badly optimized
> code that goes to work on the results later.
Hard to say from what I know.
> a way of extracting and specifying the interesting content from the h=
arvested
> feeds and links their articles point to
>
> Well the links you should be able to see in a per feed/category link map =
(I noticed
> it was broken hopefully it will work from now on) As per specifying conte=
nt through
> an Xpath what is it that you hope to gain by that? Give me a specific exa=
mple
> please.
Most feeds don't contain actual text which I'm interested in but only a
link. That means I have to click around too much. For example, the BBC
News http://www.bbc.co.uk/news/ feed
http://feeds.bbci.co.uk/news/rss.xml gets me onle short line and a link.
I would like to see the link directly without clicking and also I don't
want to see the whole page with all that redundant junk but only the
text of the article. That text is inside of <div class=3D"story-body"> so
I could specify xpath
/html/body/div[2]/div[2]/div[2]/div/div[2]/div[2]/div[2]/div and the
feed reader would automatically display just the portion of page I am
interested in.
> The main imperative for me to create the reader is the fact that the
> Google Reader's GUI is horrible IMO and I'm happy with that part of
> VizReader. That and I thought it would be an easy thing to start out
> with in PL, but there is more to a feed reader than meets the
> eye... If I had thought about making the application distributed right
> from the start I would've been even happier.
Sure, you have different motivation and way of reading news which
doesn't match with my way. That's why I also suggested exporting a
personal feed of collected feeds or sending that stuff by email.
> In the beginning I also had an algorithm that compared articles for
> automatic recommendations of similar content, that worked for a short
That could be interesting but not something crucial I would need.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
