Re: [Monotone-devel] [PATCH] mtn automate set_option

[Ben Walton]

Yah, I'm new, but I may be missing the point a little still.  When
thinking in the context of wrapping mtn in a gui (the whole point of
the automate commands), isn't it desirable to have a programmatic
interface to things like the options file?

It's not a mainstream, everyday feature by any means, but if it's not
in mtn, it would end up being duplicated in each gui that wraps mtn.
Hiding inside the automate family of commands allows the mtn backend
implementation to change without necessarily affecting the clients
that use it.  If all of a sudden _MTN/options was to be called
_MTN/options_v2, only mtn would need to be modified, not the gui
wrappers, for example.  It could also hide renamed options, but
accepting old_name || new_name as well, providing a migration path for
clients to update their code.

Apologies if I'm off base with my line of thinking.

Also, I'm just looking for more things to hack on to get into the code
more.  If my patches aren't useful, that's ok.  I've learned more
about mtn by writing them, so they're still useful to me, if only as
an exercise.

Thanks
-Ben

On 12/22/06, Thomas Keller <address@hidden> wrote:
> Nathaniel J. Smith schrieb:
> > On Thu, Dec 21, 2006 at 03:04:22PM -0500, Ben Walton wrote:
> >> I cooked this up today as a corollary to get_option.  I hope it's useful.
> >
> > So, umm... before investing time in reviewing the patch, rewriting
> > internal interfaces, answering future support questions, etc... _do_
> > you have any ideas where it would be useful?  Because I'm not really
> > sure myself (_MTN/options is really an implementation detail kind of
> > thing, and now that I think about it get_option is really unlikely to
> > survive into mtn 1.0), and it seems silly to spend that time unless
> > it's plausible that there will be commensurate rewards?
>
> Don't get me wrong, but how is he supposed to know that? Maybe we should
> start and explicitely name / comment certain things as "temporary, will
> be replaced", so no manpower goes into that?
>
> In the end get_option as well as set_option is just some interface to
> something which has been introduced into monotone for some time
> (workspace options), probably long before I knew monotone, but didn't
> get proper UI support until now. IMHO there are use cases when
> get/set_option is useful, now the question is if these use cases should
> get support or if we should throw them over because they're just of
> temporary nature?
>
> Thomas.
>
> --
> ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
>  > Guitone, a frontend for monotone: http://guitone.berlios.de
>  > Music lyrics and more: http://musicmademe.com


--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <address@hidden>

Unanswered questions are far less dangerous than unquestioned answers.
- The Roadside Pulpit
---------------------------------------------------------------------------------------------------------------------------