[Cosmo-dev] space usage reports

[Brian Moseley]

On 11/9/06, Jared Rhine <jared at wordzoo.com> wrote:

> It'd be good for the future docs to be clear about what's being measured
> with the size; I assume it is content-length.  The zero-length items got my
> attention.

i've updated the wiki page to be specific about what's measured and what's not.

collections are represented as zero-length as are directories in the
find output you specified in your enhancement request. if you'd prefer
another representation, just let me know.

> You heard me wondering if adding the mime type as a column would be helpful.
>  I'm still on the fence about that; I could see it being useful in
> reporting, though I suppose I could also script up a report based on
> filename extension.  It could introduce some difficulties, as in, what's the
> mime type of a collection (directory)?  It looks like I outlined "Which
> types of resources are consuming the most space for a user" as a use case in
> the original ticket writeup, so maybe that argues for mime-type inclusion by
> default.

i'd prefer to leave this part up to you, because only you know what
media types you really care about and which would just be a waste of
bytes over the network, but if you wind up feeling strongly about it,
i can do it for you. we could just not display a media type for
collections.

> What's the auth scheme?  Admin user only?  If so, I'm not going to worry
> about denial-of-service attacks, and I'd prefer to keep the aggregate report
> available.  As with paging of the user list, I don't yet care and tend to
> think that paging isn't actually going to cut down on computational load much.

noted in the wiki page that the function is only available to admin
users. you're probably right about paging - the major saving would be
in transmission time and size, but you'll probably always be doing
this over the local network, so that's not such an issue.

> Regarding timestamp format, that's vaguely thorny.  I tend to prefer regular
> ISO 8601, which I see is close enough to RFC 3339 that we're talking about
> the same thing.

yep, rfc 3339 is just a particular format for iso 8601 dates.

> To the question of "should we list by uid instead of path", I've realized
> I'm not sure if you're talking about users or resources.  I think I prefer
> path in both cases, though maybe you'd like to show an example of what
> by-uid would look like.

i'm talking about resources. it would just be a flat list of items
with no expressible hierarchies - the item soup we keep talking about.
probably not very useful, especially since 0.6 won't have a way to
address non-collection items by uid (coming in 0.7 i think). so let's
just leave what we have now.

> I think that totals and subtotals are better not included here; they are
> really more a UI function and if they are included, then any client-side
> scripting logic needs to parse some lines differently than others, an
> unnecessary complication.

sounds good.

> Regarding XML format, using the accept headers isn't bad.  It'd be nice to
> be able to pass it in optionally as a query param too though.

yea, or even just a path selector, eg /cmp/server/usage/space/xml. i
think http content negotiation via accept header is going the way of
the dodo.