just wondering. afaik tools such as yaourt, when you search a package, they will search for http://aur.archlinux.org/packages.php?K=<packagename> and parse the output, right?
wouldn't it make sense to have a daily crontab on the aur server that generates a file which contains all packages (maybe along with their description) ? then users can do local searches instead.
Dieter
On 31/12/09 14:42, Dieter Plaetinck wrote:
just wondering. afaik tools such as yaourt, when you search a package, they will search for http://aur.archlinux.org/packages.php?K=<packagename> and parse the output, right?
wouldn't it make sense to have a daily crontab on the aur server that generates a file which contains all packages (maybe along with their description) ? then users can do local searches instead.
Dieter
Most if not all the others use http://aur.archlinux.org/rpc.php. The local search would be nice though.
Dieter Plaetinck wrote:
wouldn't it make sense to have a daily crontab on the aur server that generates a file which contains all packages (maybe along with their description) ? then users can do local searches instead.
Even compressed, the metadata would probably take up a few megabytes. The downloads would account for a good deal of excess traffic. Perhaps the metadata could be mirrored, but the AUR is unsupported.
It is a neat idea!
-- Chris
On 31/12/2009, at 10:46 PM, Nathan Wayde wrote:
On 31/12/09 14:42, Dieter Plaetinck wrote:
just wondering. afaik tools such as yaourt, when you search a package, they will search for http://aur.archlinux.org/packages.php?K=<packagename> and parse the output, right?
wouldn't it make sense to have a daily crontab on the aur server that generates a file which contains all packages (maybe along with their description) ? then users can do local searches instead.
Dieter
Most if not all the others use http://aur.archlinux.org/rpc.php. The local search would be nice though.
It would make more sense to expand upon the RPC and use a client which caches. Initially any queries might be slower, but the second time they would be just as fast, without the overhead of downloading _all_ packages..
On Thu, Dec 31, 2009 at 10:22, Sebastian Nowicki sebnow@gmail.com wrote:
It would make more sense to expand upon the RPC and use a client which caches. Initially any queries might be slower, but the second time they would be just as fast, without the overhead of downloading _all_ packages..
+1
On Thu, 31 Dec 2009 13:46:34 -0500 Daenyth Blank daenyth+arch@gmail.com wrote:
On Thu, Dec 31, 2009 at 10:22, Sebastian Nowicki sebnow@gmail.com wrote:
It would make more sense to expand upon the RPC and use a client which caches. Initially any queries might be slower, but the second time they would be just as fast, without the overhead of downloading _all_ packages..
+1
wtf was i thinking
20k packages, say 100 bytes each -> 2GB of metadata
caching would be a much better idea indeed! and initial queries wouldn't be noticeably slower. writing a few hundred bytes to a filesystem is nothing compared to doing http requests. i guess most is said now, we should just get in touch with the guys who develop our favorite aur frontends.
/me off to celebrate 2k10
Dieter
On Thu 31 Dec 2009 19:52 +0100, Dieter Plaetinck wrote:
wtf was i thinking
20k packages, say 100 bytes each -> 2GB of metadata
Nah. The AUR database currently takes up about 44M uncompressed. That's including all user data, comments, dummy packages, etc. All the files in unsupported take up 529M. Still, it's silly to pull data for every single bloody package especially if you're not interested in 99% of them.
caching would be a much better idea indeed! and initial queries wouldn't be noticeably slower. writing a few hundred bytes to a filesystem is nothing compared to doing http requests. i guess most is said now, we should just get in touch with the guys who develop our favorite aur frontends.
/me off to celebrate 2k10
Happy New Year!
aur-general@lists.archlinux.org