剔除子节点是有效的 WURFL 搜索策略吗？
我已经实现了基于 WURFL 的检测例程，该例程基于与 http://wurfl 中概述的两阶段第一阶段类似的策略.sourceforge.net/newapi/ 。
这运作良好，但如果可以的话，我想改善最坏的情况。
在最坏的情况下，目前，每个设备的用户代理字符串都会与当前的用户代理字符串进行比较。
我很好奇的是，搜索设备树并剔除设备匹配不达到最小匹配阈值的整个分支的有效性如何？ （显然忽略没有用于匹配的用户代理字符串的“根”设备）
用户代理字符串是否倾向于遵循随着树的下降而越来越接近匹配的一般模式......从而使前述策略有效？ ...或者用户代理字符串在父子设备匹配方面是完全随机的野兽，我真的每次都被迫搜索整个树？
I've implemented a WURFL based detection routine based on a similar strategy to the two phase one outlined at http://wurfl.sourceforge.net/newapi/ .
This is working well but I would like to improve the worst case scenario if I can.
In the worst case scenario, at the moment, every device's user agent string is compared against the current user agent string.
What I'm curious about is how valid it would be to search the tree of devices and cull entire branches where device matches don't a minimum match threshold?
(Obviously ignoring 'root' devices that don't have user agent strings intended for matching)
Do user agent strings tend to follow a general pattern of ever closer matches as one decends down the tree... and thus make the aforemention strategy valid?
... Or are user agent strings a completely random beast in terms of parent verse child device matches and I really am forced to search the entire tree every single time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
WURFL-Pro 是 wurfl 项目旁边的公司，拥有双重许可策略。您可以要求他们获取一个非 GPL 的库。
要了解 wurfl java api 实现，您只需浏览 svn 上可用的源代码...或询问作者。
WURFL-Pro, the company beside wurfl project, has a dual licensing strategy. You can ask them to obtain a GPL-free library.
For know the wurfl java api implementation you can just browse the source available on svn...or ask to the authors.