RE: [core-dev] metadata searches

Hey Adam,

No resolution on it yet.  We've mainly been focusing on getting 4.2 out the
door with bugs fixed, and making sure the firewall-to-firewall transfers
work (which they do, really really well -- we had trouble the other day
finding a transfer that would fail while attempting to reproduce a bug).
We're also trying to scrounge up bandwidth before we let the whole network
know the new version exists.  A new installer that uses network resources
(and perhaps also a publishing mechanism to push the installer, or just the
necessary files for installation) is being planned so we don't have to worry
about this again.

The 200 character limit has been there for a long time (yup, you added it!),
but we never used to check the number of characters when doing a search, so
the peers receiving it would silently drop it.  Without the instant feedback
of "Your search is too big", we never noticed just how small the search
limits were.  

Another XML problem is the overhead associated with using DOM.  We have a
branch ready to be merged in that uses SAX instead, giving a good
performance boost.  Aside from that, the 200 character limit and the
searching oddness which Gregorio outlined, are there any other XML things we
should take a look at while reviewing how LimeWire handles its XML searches?

Thanks,
 Sam


> -----Original Message-----
> From: [email protected] [mailto:core-dev-
> [email protected]] On Behalf Of Adam Fisk
> Sent: Saturday, December 04, 2004 7:37 PM
> To: [email protected]
> Subject: Re: [core-dev] metadata searches
> 
> This looks like an extremely important issue, Gregorio.  Any resolution
> on this guys?  I was also noticing that the 200 character limit on XML
> searches is really, really low.  As it is, the schema location stuff
> takes up most of the xml query, with real key/value pairs taking up less
> than half the characters.  This seems strange to say the least.  I think
> boosting this to 300 would make a lot of sense.  As it is, entering a
> search that includes an artist, album, title, and genre will usually
> result in the query that's too big.
> 
> Granted it's a bit of an issue because so many clients out there already
> limit things to 200, so an increase wouldn't take effect until more
> clients got out there.  Who wrote that stupid line of code anyway (i.e.,
> I think it was me =).
> 
> -Adam
> 
> 
> Gregorio Roper wrote:
> 
> > Hello,
> >
> > I'm seeing a few weaknesses with LimeWire's XML searches:
> >
> > LimeXMLUtils#match() requires does some sort of weird prefix matching:
> > A query for artist="Bach" will not match audio metatdata where
> > artist="J. S. Bach", why doesn't LimeWire split up the query in
> > keywords as in the file manager? Note that if the file name matches
> > but the XML document does not match, the result will not be sent, so
> > this will cause many results that are otherwise almost perfect matches
> > not to be sent.
> >
> > Using different instances of Trie for the pathnames and the XML
> > documents of the shared files, causes all sorts of strange behaviour:
> > A query for (artist="J. S. Bach", title="Adagio") will match an audio
> > file WITHOUT metadata saved in the path "/home/mp3/Johann Sebastian
> > Bach/Adagio For Strings.mp3" but it will not match an audio file
> > stored at "/home/mp3/Adagio For Strings.mp3" WITH (artist="J. S.
> > Bach") as metadata.
> >
> > I'm actually surprised I'm getting as many results for my audio
> > queries as I do using audio searches....
> >
> > mfg
> > gregorio
> > _______________________________________________
> > core-dev mailing list
> > [email protected]
> > http://www.limewire.org/mailman/listinfo/core-dev
> >
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev

_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev