Shawn,
> > The approach that you're taking now doesn't need to employ streaming.
> > You could just write the tarfile to a temporary file, serve it, and
> > delete it. I'm not sure that's the right approach, though. Are you
> > sure there's no sneaky way to get CherryPy to write a streaming response
> > with an unknown length?
>
> The issue is not the unknown length; cherrypy doesn't care about that.
>
> The issue is that cherrypy does not provide a file object to write to
> for the response.
This was why I asked if there was some sleazy trick we could play to
obtain the file object. The output has to go back to the requestor over
a socket, so there's a descriptor for it _somewhere_. I just wondered
if we might be able to get hold of it through the framework by doing
things we weren't supposed to do.
> One possible thought I had was to try creating a temporary file and
> use that for the tarfile object, and after each tar_strem.add(),
> stream the temporary file and then truncate it. I would repeat that
> until done. However, I'm not sure if such chicanery would work :-)
Me either. Another thought would be to write a separate streaming
filelist daemon and use Apache's reverse proxy to map filelist ops to
the separate service.
> > There has been a fair amount of hand-wringing about how filelist doesn't
> > fit with our architectural principles. Perhaps now would be an
> > opportune time to investigate whether we could switch to sitting behind
> > Apache and simply pipeline our requests for multiple files?
> > To be clear, I'm not implying that you should do that work all by
> > yourself.
>
> I was actually considering that. The problem I have is that, as
> Stephen pointed out, the current protocol must be supported for a
> while. As such, that would have to be /filelist/1/.
I was imagining that this would simply be a bunch of GET /file/0/
requests pipelined together. We'd need to write a httplib that can
issue pipelined requests, as no Python implementations seem to do this
yet. I'm also not sure how many requests Apache will serve before it
says enough is enough. (Can we request 64 different files at once?)
> > catalog.py:
> >
> > I'm a little slow this morning. Why do we need to embed two different
> > methods in catalog.send()? I'm sure it's justified. I'm just having a
> > hard time figuring out why.
>
> The test cases for the api need the ability to output the catalog to a
> file directly.
>
> I can either move the file generation code to the tests and flatten
> this function, or leave it as is.
>
> Either one is fine with me.
I don't have a preference. I was just curious and under-caffeinated.
> > updatelog.py:
> >
> > 26 - This module is common to the client and the server. Unless I'm
> > being a moron, this import means the client will also depend upon
> > cherrypy being installed.
>
> However, I have worked around this by passing in the request and
> response object to the function as arguments.
Thanks.
> One of the things I struggled with while making these changes was
> whether it was more efficient to pass the request and response object
> around (and cleaner) or whether it was better to simply use the
> singleton object to access them.
My guess it that it might be faster to pass the request and response
object; however, the difference probably isn't enough to be appreciable.
> > repository.py:
> > 307 - Does serve_file return a 404 if it can't find the file at the path
> > that it has been given?
>
> If you specify a request path that cherrypy is unable to map to an
> object through the "mounted object tree" (see quickstart in depot.py)
> it will pass it off to the default page handler if you have one. If
> you don't have one it will return a 404.
>
> So yes, currently the depot code is setup with a custom default page
> handler that will return a 404 for unknown pages via face.py:unknown.
I guess I may have asked this question obliquely. I was trying to
figure out what happens if the client requests as filehash that isn't in
the depot. The code in file_0 looks like this:
return serve_file(os.path.normpath(os.path.join(
self.scfg.file_root, misc.hash_file_name(fhash))),
'application/data')
So if fhash isn't in the depot and the path we pass to serve_file
doesn't actually name a file, do we get a 404 here or an exception?
If I read your response correctly, this is a 404. I just wanted to make
sure I understood.
Thanks,
-j
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
