Re: [core-dev] metadata searches

Hey Sam-

Thanks for getting back to me so quickly.  That's really exciting the 
firewall to firewall transfers are working well -- what a fantastic 
improvement to the network! 

Yeah, I was surprised at how few search fields would actually fit within 
that search limit.  The DOM overhead is very interesting.  I remember 
Chris Holmes talking about SAX being faster -- great you guys are 
implementing that!!  The only other XML issue I noticed was that the 
syntax of the Lime XML chokes on newer parsers.  The newer parsers 
dsiplay the following "fatal error":

"The prefix "xsi" for attribute "xsi:noNamespaceSchemaLocation" 
associated with an element type "audios" is not bound."

It wants something like 
"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="blah" instead of just 
"xsi:noNamespaceSchemaLocation", something like that.

Not that this necessarily affects any clients out there.  If any clients 
chose to implement the Lime XML query scheme, though, they would want to 
use up-to-date XML parsers that would not accept the Lime XML as valid, 
which would be odd.

I'd be curious to see if any of the Lime schemas validate with the newer 
validators.  I guess it seems like the XML code in general could use a 
nice thorough tune up to get up to date with the newer specs.

I'll let you guys know if I notice anything else.

-Adam


Sam Berlin wrote:

>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
>
>  
>
_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev