John Rice wrote:
> 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.
Two things. First, the proposal below has nothing to do with the
existing bug (Note I've changed the subject line).
Second, there are times when exceptions aren't adequate (and are fairly
heavy weight) for passing messages. For example, in this situation, the
install succeeded. IMO, that means that
install/imageplan.execute/whatever shouldn't be throwing an indexing
exception up the stack. Your data on disk has been changed, your BE has
been updated, etc... If we separated out the indexing from
imageplan.execute, something I'd probably be against for code
maintenance issues (but don't have strong feelings about) then the
imageplan.post_execute_update_index method could throw an exception and
it would be up to the caller to adequately handle telling the user the
install succeeded but the index update failed.
Brock
>
> 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
