Re: Re: [Monotone-devel] Extensions to automation, again

[Grahame Bowland]

On 19/10/06, Nathaniel Smith <address@hidden> wrote:
> On Wed, Oct 18, 2006 at 06:53:32PM +0200, Thomas Keller wrote:
[snip]
> > automate get_file_type PATH [REVISION]
> >  -> returns the file type binary/non-binary, again for the current
> >     or any other revision
>
> Monotone doesn't actually have any concept of "binary/non-binary".
> What do you want this to return?  When you ask it for a textual diff
> then it makes a guess at whether this is actually a good idea (using
> some somewhat obscure and probably imperfect logic), but this is just
> a heuristic that it applies on the fly.

I think it would be far more useful if monotone stored mime-types as
an attribute; this is a potential can of worms though. At the moment
ViewMTN is using an implementation of the shared-mime-info spec
(http://tinyurl.com/ug9pg) to determine an appropriate MIME type,
falling back to a simple binary/non-binary check. Other MTN frontends
should be able to take this code.

> > automate get_file_size PATH [REVISION]
> >  -> returns the size in Bytes of the file in that version in history
>
> We could store this in the db for efficient access -- it wouldn't
> require any messing around with the network formats, because we
> already have to reconstruct files when they enter thet database (to
> check their hashes), and we could note down their size then, too.
>
> But, if we're going to commit the design and maintainence effort to
> providing a fast get_file_size command going forward, then we need to
> make sure that there are real use cases to justify that.  I'm not
> totally convinced yet -- are users really running diff all the time on
> giant files, and then getting confused when it takes a bit for the
> "busy" indicator to clear and the diff to appear?  If so, is the best
> solution really to build in a heuristic that files above a certain
> (hard-coded?) size are "large", and give the user an extra warning in
> such cases?
>
> (Regardless, the ability to display diffs is obviously useful even
> without such warnings, so resolving this question isn't urgent until
> there actually is a command to display diffs.)

I think it's useful for a user wanting to download or examine a file
in a web interface to MTN to be able to find out ahead of time what
the file size is. I can't reasonably provide that in ViewMTN at the
moment, as determining file size is too expensive.

I make quite a bit of effort to stream data to the user down the HTTP
connection as quickly as MTN sends it to ViewMTN. If the user is
downloading a single file, the lack of file size information isn't the
end of the world. However, if I want to efficiently stream a tar file
of net.venge.monotone to a user without having to buffer every file
twice (once inside Monotone, once inside my application) I need the
size information ahead of time.

I see it as being useful that external tools can deal with large files
(greater than the amount of RAM in the host machine) knowing their
size in advance, and push back to Monotone the problem of how to deal
with these memory constraints.

I'd also like to implement WebDAV support for ViewMTN - I've been
actively looking into this. To get that going file size information
will be fairly vital.

[ I just realised it might come across that I'm "demanding" this
feature - I don't mean to; I'll attempt to muck in if there's a
consensus it's desired. ]

Cheers
Grahame