> > Locally is ment as on the server of the patches archive. Remote in this
> > meaning would be on the site of the maintainer of this patch. The idea
> > is that the maintainer only needs to update the description file on
> > his download page - the server which holds the patch archive updates his
> > copies automatically (lets say every 4 hours - this files are not big).
>
> Ah, OK. I was misunderstanding you. Maybe the patch maintainer could
> have some way of triggering the script to be run whenever he updates
> something? Checking all the patches every 4 hours would presumeably
> generate a significant amount of unneeded traffic, and might there be
> problems if servers go down?
I don't see so much traffic for this. Since bugfixes are not allowed I
don't thing that there will be more than a maximum of a few hundret
patches. HTTP and FTP support updates - this means that the file is only
downloaded again if there is _really_ a newer version of it. Otherwise
it's just establishing a TCP connection and sending a few heders in both
directions. (BTW: does linux support TCP for transactions?)
The reason for this is that there should be allmost no efford for the
maintainer of a patch - otherwise the archive would be outdated pretty
soon and an old archive is worse than no archive ...
If the server is down the connection would time out and the patch would be
updated 4 hours later - probably a message could be sent to the maintainer
of the archive at such an error or a "no such file" error so he knows that
the patch probably disappared ...
- clifford
-- -- -- -- -- -- -- -- -- -- -- -- --
Clifford Wolf (CEO and CTO)
The ROCK Projects Workgoup IRC: IRCnet / clifford
http://www.rock-projects.com/ http://www.clifford.at/
e-mail: c.wolf@rock-projects.com email: god@clifford.at
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/