kwazthis should handle destination dirty buffers.
OpenPublic

Description

Given a local_repo, it is ideal for us in editor land if kwasthis actually computed the right offset when the destination file(which defines the element) is dirty.

Thank you!

amshali created this task.Via WebJul 10 2015, 3:57 PM
amshali assigned this task to schroederc.
amshali added a subscriber: amshali.
schroederc added a subscriber: fromberger.Via WebJul 10 2015, 4:00 PM

As we've discussed offline, the xrefs service doesn't currently support dirty destinations. We would have to either add a new API call or do the mapping locally.

@fromberger, do you have any strong opinions on this front?

fromberger added a comment.Via WebJul 13 2015, 6:41 AM

I think it makes sense to have the cross-reference service support this—at least for file decorations, as it'd be a lot of fairly subtle position-munging logic for the client to carry around.
We should think about how we might want to do it, though; e.g., does the client send the whole buffer, or just the diff itself?

amshali added a comment.Via WebJul 13 2015, 11:04 AM

This would be awesome for us.
Cody added this local_repo flag which can be used to look up any dirty buffer by a path.

schroederc changed the title from "kwasthis should handle destination dirty buffers. " to "kwazthis should handle destination dirty buffers. ".Via WebJul 14 2015, 8:52 AM
schroederc triaged this task as "Low" priority.Via WebJul 21 2015, 10:19 AM
schroederc added a comment.Via WebJul 21 2015, 10:22 AM

@fromberger, do you agree that this should be a new API method then?

fromberger added a comment.Via WebJul 21 2015, 10:42 AM
In T52#588, @schroederc wrote:

@fromberger, do you agree that this should be a new API method then?

Do you think it should be a separate method? I don't object, but it seems like it's an aspect rather than a separate method.

schroederc added a comment.Via WebJul 21 2015, 11:16 AM

@amshali, how would like a service interface to look for this kind of use case?

Do you want to send the server all of the known dirty files in the FileDecorationsRequest? Or do you want to make an additional call to patch anchors given a dirty buffer (as a new API call)? Or something else?

amshali added a comment.Via WebJul 21 2015, 11:18 AM
In T52#590, @schroederc wrote:

@amshali, how would like a service interface to look for this kind of use case?

Do you want to send the server all of the known dirty files in the FileDecorationsRequest? Or do you want to make an additional call to patch anchors given a dirty buffer (as a new API call)? Or something else?

No I don't want to do that. I just wish to send the dirty destination one.

fromberger added a comment.Via WebJul 21 2015, 11:21 AM
In T52#591, @amshali wrote:

No I don't want to do that. I just wish to send the dirty destination one.

I think there are two related issues: One is how to patch references in a dirty file, so that they move.
The other is how to patch the *targets* of references, that point to other dirty buffers in your client view.

Right now, the latter is something we do not support at all (even in the internal implementation). But if you're expecting a client view to link to other modified files in the same view, that's something we'd need to figure out. In the limit, the client view could have a *lot* of modified files. I expect in general it'll be a fairly small number, though.

amshali added a comment.Via WebJul 21 2015, 11:32 AM
In T52#592, @fromberger wrote:
In T52#591, @amshali wrote:

No I don't want to do that. I just wish to send the dirty destination one.

I think there are two related issues: One is how to patch references in a dirty file, so that they move.
The other is how to patch the *targets* of references, that point to other dirty buffers in your client view.

Right now, the latter is something we do not support at all (even in the internal implementation). But if you're expecting a client view to link to other modified files in the same view, that's something we'd need to figure out. In the limit, the client view could have a *lot* of modified files. I expect in general it'll be a fairly small number, though.

I don't want to send all the dirty buffers to the server. But if we assume that there are just a few of those, maybe it's ok to give them to server. On the other hand when we are doing jump to definition, there is only one target file. If that is dirty I want the grok service to be able to remap the locations in that file given a dirty buffer which I can provide.

fromberger added a comment.Via WebJul 21 2015, 1:36 PM
In T52#593, @amshali wrote:
In T52#592, @fromberger wrote:

I think there are two related issues: One is how to patch references in a dirty file, so that they move.
The other is how to patch the *targets* of references, that point to other dirty buffers in your client view.

Right now, the latter is something we do not support at all (even in the internal implementation). But if you're expecting a client view to link to other modified files in the same view, that's something we'd need to figure out. In the limit, the client view could have a *lot* of modified files. I expect in general it'll be a fairly small number, though.

I don't want to send all the dirty buffers to the server. But if we assume that there are just a few of those, maybe it's ok to give them to server. On the other hand when we are doing jump to definition, there is only one target file. If that is dirty I want the grok service to be able to remap the locations in that file given a dirty buffer which I can provide.

I think there's an open question of what to send to the server. The contents of dirty files is certainly the easiest to understand, though it could potentially be a lot of data. Compression could help if we went that route. But it could also just be a unified diff, for example—which would be smaller and easier for the client to cache. I'm not sure what makes most sense.

If possible, I'd like to avoid the server having to keep state. It could maybe make sense to have per-session state, but I'd prefer we explore the stateless options first.

schroederc added a comment.Via WebJul 21 2015, 1:37 PM

I definitely don't want to have state either.

schroederc added a comment.Via WebJul 30 2015, 11:03 AM

@amshali, what do you think of a proxy server that exposes the same API surface as the http_server and transparently does patching on all API calls (including Nodes) based on a given local repository? This would allow for destination patching as well as better performance since the proxy can attempt some caching.

amshali added a comment.Via WebJul 30 2015, 11:11 AM

I would love that. Is it possible to run multiple proxies? Because we might have multiple project(repos) open.

schroederc added a comment.Via WebJul 30 2015, 11:14 AM

What's your current setup for multiple projects? Do you have multiple servers running?

Running the proxy shouldn't be any different than running the http_server other than the additional flag(s) to determine where to find the dirty files.

amshali added a comment.Via WebJul 30 2015, 11:19 AM

Can proxy accept multiple

local_repos
```?
Our current setup relies on calling the command line tool with a new local_repo everytime. I suppose I will do the same thing with proxy and it will just figure out the rest?
schroederc added a comment.Via WebJul 30 2015, 11:21 AM

Is there 1 http_server running per project?

amshali added a comment.Via WebJul 30 2015, 2:08 PM

No. 1 for all

schroederc changed the visibility of this Maniphest Task from "All Users" to "Public (No Login Required)".Via WebMay 16 2016, 3:30 PM
schroederc placed this task up for grabs.Via WebJun 13 2016, 12:22 PM
schroederc lowered the priority of this task from "Low" to "Wishlist".
schroederc removed subscribers: fromberger, amshali.

Add Comment