Brock Pytlik wrote:
jmr wrote:
Folks - I'd like to clarify a few things.
At the minute we have a per repository view. With large number of
packages it is not working well for type ahead search. There are some
things we can do to improve the situation, but until we have a
scalable solution I'd vote for turning it off (I had added the
preferences dialog setting, but given Glynn's comments, am happy to
just turn off the feature and leave the gconf key there for those who
want to turn it on). In the meantime Michal's web rev is still useful
for us to improve overall category browsing and startup performance,
when coupled with a cpickle cache for the repo.
I'm glad that we're going with turning it off for now. I hope you'll
consider the solution I proposed earlier for how to handle type ahead
search, at least as long as the search box is only searching package
names, in a way that might scale better, or let me know why it's a
dumb idea.
Ok - we can discuss when we are over.
I have no objection at all to a unified cross repository view but
this is not something we can achieve with the current implementation.
As various folks have suggested we could move over to a search based
implementation, where we populate a Tree View on the left hand side
with category nodes from all registered repos, then as a user clicks
on one of these nodes issue the appropriate search to populate the
right hand list view. When we have a search api in place and its
performant enough to allow this to happen its something we could do,
but not for this release. We can discuss possible designs with
xDesign when the support is in place. It should be noted that a
search based approach is not the only solution as Ubuntu have
demonstrated with their caching implementation that supports cross
repository browsing.
To be clear, the suggestion I laid out for browsing doesn't line up
with anything you've stated above, and had nothing to do with search.
Ok - we can discuss when we are over.
I guess I don't understand why it's not possible to achieve a unified
view with the current implementation, but I'll accept that it's not.
If that's the case, then since all that code will need to be rewritten
anyway, I guess there's no problem with the putback b/c we're not
moving further from a unified view, we're already as far as we can get.
Ok - Michal will put back and followup with his cache support changes
webrev.
As a side note, remote search, which is what I presume you mean when
you're talking about it above, is performant now (or likely as
performant as it's going to get anytime soon). The interface to remote
search will be changing slightly, but not a huge amount. So developing
against what's there today will get you 90%+ of the way to what's
coming soon, and I can hand you a workspace with the search API
changes in it if that's helpful so you can start testing them if you'd
like. I'm not sure why having the API is a prerequisite for discussing
a design with xDesign, but the API is basically settled pending
feedback from consumers. I'm happy to put out a preliminary webrev and
keep it reasonably updated as well if that'd help.
It would be great to have a preliminary Search API webrev so we can work
on this next week, before we come over.
Thanks,
JR
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
