On 16/5/2004, at 11:36 AM, Gavin Sinclair wrote:
> On Monday, May 17, 2004, 1:11:13 AM, Curt wrote:
>>> Chad Fowler wrote:
>>>>>> I'm all for making the API more convenient and powerful, but I don't
>>> think I'm very close to being sold on doing it via Gem inheritance.
>>> In
>>> this context, I'd say that a gem is a gem. You can store it locally
>>> or
>>> remotely and you can install and uninstall it, but it's still a gem.
>>> These really *are* processes, right?
>>>>>> I could see how this could be an argument for getting a little more
>>> uniform about how we represent a "repository". Maybe that's the noun
>>> you're looking for? Right now we call that 'cache', which I know you
>>> hate. :) Should we look at doing local and remote ones in an OO way?
>>> I'm not sure.
>>> I haven't looked at this in a few weeks, to maybe it has changed, but
>> the
>> main file that implements the command line interface mixes API with
>> command
>> interface. I remember wanting to separate these so that the command
>> line
>> process requires/uses the same API file my GUI browser would use,
>> No, nothing's changed :( That's definitely something we need to
> address, but it may take a bit of sleeves-up dirty work. I'm happy to
> do the dirty work, but I'd like some help from you on what the API
> should look like.
>> It's important to remember that various events can happen inside the
> API that different clients will handle differently. For example,
> getting confirmation before installing a slew of dependencies. Your
> client does something with dialog boxes; 'gem' uses STDOUT/STDIN. We
> need to model that sort of interaction adequately.
>
Somewhere on one of my hard drives I have a continuations-based
solution to this that kind of looks like resumable exceptions. The
intent was to generalize it and make a generic solution for UI
interaction, but I hit a wall and got demotivated. :) Let me see if I
can find it as a potential inspiration to someone who can see past the
problem I couldn't solve.
Chad