Mailinglist Archive: zypp-devel (227 mails)
| < Previous | Next > |
Re: [zypp-devel] [SoC-student] libzypp HTTP download failover
- From: "Dr. Peter Poeml" <poeml@xxxxxxx>
- Date: Thu, 3 Apr 2008 14:03:45 +0200
- Message-id: <20080403120345.GA6056@xxxxxxx>
On Fri, Mar 28, 2008 at 09:53:52PM +0100, Dr. Peter Poeml wrote:
Yesterday, metalink support in the redirector became a reality.
*However*, while working with the metalink format it became clear to me
that is more desirable *for libzypp* to have a its own, text-only,
format.
This in order to avoid dependencies on a library parsing XML, and avoid
the work of parsing altogether. As indicated in an earlier mail, it is
totally appropriate and sufficient if libzypp just reads the first line
of the mirror list and follows that URL.
But if you say, libzypp has XML support anyway (I suppose it would have,
in order to be able to use repo-md repositories), metalink support is
(nearly) there.
This is prabably also the same way that metalink support is going to
work, for enabled clients.
Metalink-enabled clients will indicate their ability, and get a
metalink, or the file. Other clients will get a redirect, or the file.
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
BTW: Checksumming *could* be done at lower level (with each file
request) *if* the mirrorlist would be metalinks (http://metalinker.org),
or have similar capabilities. Those contain checksums which can be used
to ensure transfer integrity. I'm contemplating about adding metalink
support to the redirector and whether that could be a way to achieve the
goal we are discussing here. There is a number of clients out there
which understand metalinks, and that would help for iso downloads just
as well -- not only the specialized libzypp client.
This is an interesting area which calls for exploration.
Yesterday, metalink support in the redirector became a reality.
*However*, while working with the metalink format it became clear to me
that is more desirable *for libzypp* to have a its own, text-only,
format.
This in order to avoid dependencies on a library parsing XML, and avoid
the work of parsing altogether. As indicated in an earlier mail, it is
totally appropriate and sufficient if libzypp just reads the first line
of the mirror list and follows that URL.
But if you say, libzypp has XML support anyway (I suppose it would have,
in order to be able to use repo-md repositories), metalink support is
(nearly) there.
2) the feature is specific to downloads.opensuse.org (for now)
- we would need to hardcode a is_download_opensuse_org condition to
avoid useless requests for other URLs (or introduce a mechanism to
query for availability of such capability and check that when
starting zypp). This would not apply if the mirror list would be
requested and processed only on errors.
It is not necessary to have such a hard-coded condition. The client can
indicate (in the HTTP request) with an HTTP/1.1 Accept header that it is
able to accept a mirror list, instead of file or a redirect to the file.
(Older clients would continue to work.)
The server can then reply with a list to those clients that send that
Accept header. The client will be able to tell by the MIME type if it
got a mirror list or a file. (And of course it will still transparently
follow redirects, regardless.)
This is prabably also the same way that metalink support is going to
work, for enabled clients.
Metalink-enabled clients will indicate their ability, and get a
metalink, or the file. Other clients will get a redirect, or the file.
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
| < Previous | Next > |