Broc - surely all we need here is to define a set of appropriate
exceptions to throw when something goes wrong and have the different
clients handle the exceptions appropriately. For us on the GUI side we
may pop up a dialog to warn the user, on the cli you might print
something out on the command line.
The exceptions are part of the API and give clients a clean way to
interact with all error conditions the API might raise. Apologies if I'm
telling you guys how to suck eggs, but this change from the cli focus of
outputting error messages in the bowels of IPS to the terminal, towards
a general approach of raising well documented exceptions is really
important if we are to have a client API with the appropriate level of
separation between the clients and the underlying IPS engine.
JR
Brock Pytlik wrote:
> Shawn Walker wrote:
>
>> Danek Duvall wrote:
>>
>>> On Tue, Aug 26, 2008 at 03:31:39PM -0500, Shawn Walker wrote:
>>>
>>>
>>>> This seems like something we should be able to figure out on our
>>>> own. We should have some way of "knowing" (by an image attribute or
>>>> a file timestamp?) that the index needs to be synchronized.
>>>>
>>> And Brock is doing precisely that. The issue is that Brock would
>>> like for
>>> the end-user to know that something had gone wrong, even if we were
>>> able to
>>> fix it successfully, on the expectation that they'll still complain,
>>> so we
>>> can a) figure out that it's happening at all, and b) we can have some
>>> hope
>>> of fixing it.
>>>
>>> A worthy goal, but I'd rather have it silent for now (unless it can't
>>> update the indices in full, either, of course).
>>>
>> I guess my point was that we shouldn't ever need to tell the user that
>> they have to go do something like "pkg rebuild-index" -- we should do
>> it if we need to (on reboot in this case). In this particular case,
>> it looks like this gets back to the discussion of having an SMF
>> service manage the search reindexing.
>>
>>
> Now you've lost me. Are you talking about a different bug ("we should
> check if the index needs fixing at boot"), or is this still this bug? I
> agree, such a service would be nice to have, but I don't see how it's
> relevant here.
>
> Also, pkg rebuild-index isn't an instant thing. It's fast, relative to
> things like install or image-update, in my opinion, but slow, in
> comparison to search for example. I'm willing to automatically rebuild
> the index in the install/image-update case because the relative
> time-penalty is small. I'm looking at getting the checking into search,
> but right now it causes too much sluggishness (I may have a wayt to fix
> that). But if the search discovers the indexes are broken one thing it
> won't do is silently rebuild them. A search that's expected to take .6s
> shouldn't take 40s without notifying the user. I'd be ok with either
> notifying the user (once we have a framework in place) and proceeding,
> or simply stopping and telling them to run rebuild-index as we do today.
>
> Brock
>
>
>> I agree that it's a worthy goal to communicate that something went
>> wrong to the user, but I also agree with you that we need a framework
>> in which to do that before we start generating that kind of feedback.
>>
>> Cheers,
>>
>
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
