[email protected] wrote:
On Thu, Jun 25, 2009 at 03:25:49PM -0500, Shawn Walker wrote:
Some other comments after poking around with the transport api today:
* I noticed a ProgressTracker isn't supported when using get_url() (or
rather, fetching single resources instead of multiple). Given the size
of some our manifests (2.8M for SUNWjruby), I think tracking the
download progress would be helpful :) In fact, updating through
packagemanager for a new release will trigger a download of at least 65
megabytes of manifest data!
This would require some pretty substantial changes to the
ProgressTracker and the API, I think. I know the GUI guys want search
to be cancelable too. It would probably be better to have byte-based
progress tracking for manifests/search/catalog/whatever be its own
separate wad, since we'll need to design something that the GUI guys can
use, and that fits into the API.
It's certainly a legitimate RFE.
That's fine, but it would provide a substantial improvement of the user
experience for the cli and gui to be able to show this.
Especially at the moment since manifest retrieval is such a black box.
* It would be good if stats.dump() included the total bytes transferred
(which I ended up hacking in my local workspace so I could compare
tools.gzip.on to off)
The existing format is pretty cramped in an 80 character terminal. I
can play with this a bit, but if it makes the output unreadable, I may
just omit it for now.
A separate RFE is fine.
* Maybe stats.dump should be changed to use misc.bytes_to_str and just
label the KB/sec column 'Speed'
* It would be nice if the additional stats that the object has as
private properties (such as __bytes_xfer) could be exposed
I should be able to do both of these.
Thanks,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
