Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] User Experience Call

> Not sure if it is doable on server side but...
>
Presumably it is if the server is running on top of a file system that is based on an Eclipse Workspace (i.e. because you could tell when things had changed based on the Workspace change notification).

McQ.


Inactive hide details for Libing Wang---2012/05/02 10:32:26--->> I would be happy to wait longer for a search result if that woLibing Wang---2012/05/02 10:32:26--->> I would be happy to wait longer for a search result if that would mean it could ensure the search

From: Libing Wang/Ottawa/IBM@IBMCA
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc: Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Date: 2012/05/02 10:32
Subject: Re: [orion-dev] User Experience Call
Sent by: orion-dev-bounces@xxxxxxxxxxx




>> I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
>Me too. Is this doable with the current architecture?

Not sure if it is doable on server side but lets assume that server is aware of the "not updated yet" state when a search request is sent to a folder.
My concern is what the UI gesture will be? Are we going to say "please wait. Index is being updated"?
If that is true I would rather switching to a crawling search instead of waiting for index being updated, where at least I am seeing search progress...

Libing



Inactive hide details for Mike Wilson---05/02/2012 08:56:07 AM---> I would be happy to wait longer for a search result if that Mike Wilson---05/02/2012 08:56:07 AM---> I would be happy to wait longer for a search result if that would mean it could ensure the search

From: Mike Wilson/Ottawa/IBM@IBMCA
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 05/02/2012 08:56 AM
Subject: Re: [orion-dev] User Experience Call
Sent by: orion-dev-bounces@xxxxxxxxxxx



> I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
Me too. Is this doable with the current architecture?

McQ.


Inactive hide details for Kris De Volder ---2012/05/01 18:44:05---> This worked for me. I wonder if you typed the line and thenKris De Volder ---2012/05/01 18:44:05---> This worked for me. I wonder if you typed the line and then immediately searched for it. That is a

From: Kris De Volder <kdvolder@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 2012/05/01 18:44
Subject: Re: [orion-dev] User Experience Call
Sent by: orion-dev-bounces@xxxxxxxxxxx



> This worked for me. I wonder if you typed the line and then immediately searched for it. That is a big current limitation in our search - because it is index based and the
> index may not be up to date at the moment you search.

It was actually quite an old file. Not something I just entered. Now that I try it again it actually does work.
Not sure why it didn't work earlier. Now I'm starting to think maybe I imagined it :-)

Problems of indexes being 'out of date' are probably adding to the feeling of 'unreliability' I get.
Though I can't say whether or not this particular case was really an example of that.

I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
before it starts searching.

Kris

    Kris De Volder <kdvolder@xxxxxxxxxx> wrote on 05/01/2012 03:27:56 PM:
    > Here's a different type of example (no white space involved).
    >
    > Say I have this line of code:
    >
    > response.end("Hello Kris");
    >
    > Now search from navigator for 'Kris'.
    >
    > It doesn't find the line above.

    This worked for me. I wonder if you typed the line and then immediately searched for it. That is a big current limitation in our search - because it is index based and the index may not be up to date at the moment you search.

    It is also definitely true that it is harder to get an index-based search to be "perfect" compared to a manual file system crawl on each search. We have been making steady improvements but I'm sure there are still problematic cases. On the flip side, our search is vastly more performant and scalable than a naive file system search. When I go back to Eclipse desktop now I am struck by how incredibly slow it is. I just did a search for "Kris" in my Eclipse desktop workspace, which isn't particularly large, and it took over two minutes. The same search on my Orion workspace, which is slightly smaller but comparable in size, took under 300ms. Performance certainly doesn't excuse any failure to find a match, but it's definitely a consideration for Orion to scale up beyond small applications and workspaces.

    Everyone please continue to report bugs if you have a search case that doesn't work...

    John
    _______________________________________________
    orion-dev mailing list
    orion-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

GIF image

Back to the top