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

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


UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to