Re: [Nautilus-list] future plans for the search feature

[Michael Rothwell <rothwell holly-springs nc us>]

How about having Nautilus just use slocate for now?


On 04 Apr 2001 20:12:36 -0400, Ryan Muldoon wrote:
> So this means that all searching will be gone in Nautilus?  That's
> unfortunate.  I was hoping that vFolders would be coming sooner rather
> than later.  But, I trust that there will be an eventual solution that
> will work out nicely.  
> 
> On 04 Apr 2001 13:44:38 -0700, Rebecca Schulman wrote:
> > 
> > I am going to remove the options to enable and disable fast search in
> > nautilus, and disable the ability to request a reindex
> > from nautilus for the time being tomorrow, unless someone objects and/or
> > proposes an alternate short term solution.
> > 
> > Also, I should be clear that removing medusa disables both the fast and
> > slow search feature, not simply the indexed search feature.  Another plan
> > for the short and/or long term would be to include the ability to do slow
> > searches in nautilus, but
> > not include indexing to make searching faster.
> > 
> > 
> > Rebecca
> > 
> > 
> > Rebecca Schulman wrote:
> > 
> > > We recently decided that potential/known  security issues involving
> > > medusa were sufficient to warrant removing the fast search feature from
> > > both nautilus for 1.0.1.  We will also be releasing 1.0.2
> > > without the fast search feature.
> > >
> > > If we would like to return to having a fast search feature in Nautilus,
> > > we need to decide on two courses of action regarding how the feature
> > > will work.  The first part of the plan is to remove the ability for
> > > normal users to configure medusa's setup, and to change the Nautilus UI
> > > to work accordingly.  The second step in the process is to decide on a
> > > specification for the search feature that minimizes security risks, and
> > > still remains close to our original vision for the feature so that we
> > > can ship a Nautilus with medusa again in the next release (1.0.3) if at
> > > all possible.
> > >
> > > I have come up with a bunch of suggestions intended to address each part
> > > of this plan.
> > > Listed with each suggestion are the advantages and disadvantages of the
> > > suggestion that I can see.
> > > These lists are not intended as any set of decisions so further
> > > discussion can certainly include things not here.
> > >
> > > Here are some suggestions on how to deal with enabling and disabling
> > > medusa when it requires a root password:
> > >
> > > (1)   Leave the "fast search" preference in its current place, but
> > > require a root password to turn the indexing feature on or off.
> > >
> > > This choice seems to require relatively few code changes, but there are
> > > a bunch of drawbacks.
> > > One is the issue of having a different "fast search" preference at
> > > different user levels.  If this happened,
> > > a user might be asked for their root password when changing user levels,
> > > which would be strange indeed.  It's also not clear that a system
> > > setting like whether your computer is indexed or not is actually a
> > > "nautilus preference".
> > >
> > > (2)  Remove the ability to turn medusa on and off in nautilus for now.
> > >
> > > We could include documentation about how to turn the search feature on
> > > as root in either the user manual, or as a dialog that came up when the
> > > search feature was activated. This is easy to implement, but probably
> > > makes the search feature, which is already hard to use, worse.
> > >
> > > (3)  Make turning medusa on and off a "system preference" which is done
> > > separately than other nautilus user preferences.
> > >
> > > We could extend the "indexing information dialog" so that  you could
> > > enable and disable medusa from here. Making this work logically would
> > > also involve making the dialog available at all times, since it is
> > > currently only available when viewing search results (This is
> > > bugzilla.eazel.com bug 3254 http://bugzilla/show_bug.cgi?id=3254)  This
> > > option would probably involve the highest level of code change of the
> > > options listed here.
> > >
> > > I am not overly excited about any of these possibilities.  My personal
> > > preference is to do (2) until we figure out what to do in the long term,
> > > even though the UI is suboptimal, since it's likely work we do for this
> > > may never be shipped.
> > 
> > 
> > 
> > _______________________________________________
> > Nautilus-list mailing list
> > Nautilus-list lists eazel com
> > http://lists.eazel.com/mailman/listinfo/nautilus-list
> 
> 
> 
> _______________________________________________
> Nautilus-list mailing list
> Nautilus-list lists eazel com
> http://lists.eazel.com/mailman/listinfo/nautilus-list