Bug 89557 – Web Inspector: [Extension API] ResourceManager APIs to map local files/repository and revision history

• Component: Web Inspector (Deprecated)
• Status: RESOLVED INVALID

[Vivek Galatage]

Current resource panel allows to navigate the resources of the Page. Even great is the fact that inspector allows to edit some of the resources(js,css) on the fly. And Resource history is just amazing feature of tracking the resource modifications.

In addition to these features, how about if the inspector allows the developers to map local files/repository and starts referring the resources from this repository? Also if the resource modifications/revisions can also be notified to the developers(extension) who then can commit these changes directly into the local/remote repositories (e.g. svn, git, github etc).

In order to achieve these features, I propose Inspector providing extension APIs for ResourceManager to map the local files as well as provide notification APIs for any resource modifications.

[Vivek Galatage]

I am planning to work on this feature. So it would be great to receive comments/feedback/suggestions on this. Thank you.

[Vivek Galatage]

I also stumbled upon http://code.google.com/p/chromium/issues/detail?id=91852 which outlines similar feature.

[Pavel Feldman]

(In reply to comment #1)
> I am planning to work on this feature. So it would be great to receive comments/feedback/suggestions on this. Thank you.

It would be nice to see a high level design / extension API that you have in mind. There already is an API that provides notifications on resource modifications.

[Vivek Galatage]

(In reply to comment #3)
> (In reply to comment #1)
> > I am planning to work on this feature. So it would be great to receive comments/feedback/suggestions on this. Thank you.
> 
> It would be nice to see a high level design / extension API that you have in mind. There already is an API that provides notifications on resource modifications.

Oh sure. So can you please point me where can I find the existing APIs? Taking that as reference I can start building the other APIs.

[Pavel Feldman]

http://code.google.com/chrome/extensions/devtools.inspectedWindow.html

See Resource.get/setContent.

[Vivek Galatage]

Created attachment 148758 [details]
Use case of ResourceManager APIs to demonstrate the web developer workflow

[Vivek Galatage]

Proposed High level APIs

inspectedWindow
---------------
Methods:
-------
    + mountResources(url resourceRoot, function callback)
      Description: Instructs inspectedWindow to mount the root of the resource tree
      
      Parameters:
        resourceRoot: local path/url to resource root directory
      
      Callback Function:
        function callback(errorCode)
        
    + mountResource(string resourceId, url urlOfResource, function callback)    
      Description: Instructs inspectedWindow to mount individual resource with resouceId to the given Resource URL
      
      Parameters:
        resouceId: Resource id
        urlOfResource: Resource url

      Callback Function:
        function callback(errorCode)
        
    + resourceForId(string resourceId)
      Description: Retrieves the Resource object associated with resouceId
      
      Parameters:
        resouceId: Resource id
      
      Returns: Resource      
        
Events:
------
    + onResourceContentChanged
      Description: This event is similar to onResourceContentCommitted in that it provides the diff in UnifiedDiffFormat
      
      onResourceContentChanged.addListener(function(string resouceId, UnifiedDiffFormat diff))
      
      Listener Parameters:
        resouceId: Resource id
        diff: The diff/patch in UnifiedDiffFormat      
      
Resource
--------
Methods:
-------
    + resouceId()
      Description: Provides the resourceId associated with the resource
      
      Returns: resouceId
      
    + resourceType()
      Description: Provides the mimeType associated with the resource
      
      Returns: mimeType
    
    + isEditable()
      Description: Verifies whether resource can be edited with inspector
      
      Returns: bool
      
    + isMountable()
      Description: Verifies whether resource can be mapped with inspector
      
      Returns: bool
      
    + applyPatch(UnifiedDiffFormat diff, function callback)
      Description: Tries to apply the Unified diff on the resource
      
      Callback Function:
        function callback(errorCode)

[Pavel Feldman]

Could you provide a "the life of a user action" story? I.e. what user sees in the UI and what happens when he chooses say "Commit" or "Diff" there?

[Vivek Galatage]

Created attachment 148987 [details]
UI Flow for depicting the Developer life cycle story

[Vivek Galatage]

(In reply to comment #9)
> Created an attachment (id=148987) [details]
> UI Flow for depicting the Developer life cycle story

Pavel, do you have any comments regarding the UI flow?

[Pavel Feldman]

(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=148987) [details] [details]
> > UI Flow for depicting the Developer life cycle story
> 
> Pavel, do you have any comments regarding the UI flow?

Yes, sorry, this is my first working day after the IO.

I think the API lacks few important pieces:
- the source tree provider. You should be able to see all the files under the folder in the inspector view, not only the ones that were loaded over the network.
- merging the files provided from the extension with the ones from the network
- ability to create new files
- the mapping should not be a part of the API and should instead be controlled by the extension (with possibility to save the mapping to file and put it into the version control

When we were thinking about this extension API in the past, we were calling it "workspace provider".

Unfortunately, implementing support for such an API requires deep refactorings in the inspector. Good news is that we were planning to extend the Resource API to have this Workspace nature earlier as well and performed some of them (introduced UISourceCodeProviders, etc). However, I think that it will be really hard for you to complete those refactoring and contribute this API without extensive help from our side. So I am thinking that we should do the API that allows providing workspace off the file system here and then you will be able to extend it with the VCS capabilities. What do you think?

[Vivek Galatage]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Created an attachment (id=148987) [details] [details] [details]
> > > UI Flow for depicting the Developer life cycle story
> > 
> > Pavel, do you have any comments regarding the UI flow?
> 
> Yes, sorry, this is my first working day after the IO.
> 
> I think the API lacks few important pieces:
> - the source tree provider. You should be able to see all the files under the folder in the inspector view, not only the ones that were loaded over the network.
> - merging the files provided from the extension with the ones from the network
> - ability to create new files
> - the mapping should not be a part of the API and should instead be controlled by the extension (with possibility to save the mapping to file and put it into the version control
> 
> When we were thinking about this extension API in the past, we were calling it "workspace provider".
> 
> Unfortunately, implementing support for such an API requires deep refactorings in the inspector. Good news is that we were planning to extend the Resource API to have this Workspace nature earlier as well and performed some of them (introduced UISourceCodeProviders, etc). However, I think that it will be really hard for you to complete those refactoring and contribute this API without extensive help from our side. So I am thinking that we should do the API that allows providing workspace off the file system here and then you will be able to extend it with the VCS capabilities. What do you think?

Sounds good to me. Whats your idea about the new APIs using the File System? Any pointers in that direction would be of great help. Also please let us know if we could be of any help on re-factoring the code base. We will be more than happy to contribute there as well.

[Pavel Feldman]

> 
> Sounds good to me. Whats your idea about the new APIs using the File System? Any pointers in that direction would be of great help. Also please let us know if we could be of any help on re-factoring the code base. We will be more than happy to contribute there as well.

Deep refactorings such as removing domain bindings from resources and unbinding Resources from UISourceCodes will take more to explain than to complete. Many things are up in the air there and providing details on the context will be not efficient. Once these are landed, it'll be way easier to explain the code base since it'll be more consistent. So please give us some time there and we'll make sure you are aware of the plans and progress of the Workspace API, we'll think if there is a way to find a separable piece there for you to tackle. It is likely to take couple of weeks, so doing the other tasks on the list that are separable would be a great option for now.

I apologize for not stating these complexities up front, but I thought that by the time you start doing VCS integration, we will already have the definition of the workspace.

[Vivek Galatage]

(In reply to comment #13)
> > 
> > Sounds good to me. Whats your idea about the new APIs using the File System? Any pointers in that direction would be of great help. Also please let us know if we could be of any help on re-factoring the code base. We will be more than happy to contribute there as well.
> 
> Deep refactorings such as removing domain bindings from resources and unbinding Resources from UISourceCodes will take more to explain than to complete. Many things are up in the air there and providing details on the context will be not efficient. Once these are landed, it'll be way easier to explain the code base since it'll be more consistent. So please give us some time there and we'll make sure you are aware of the plans and progress of the Workspace API, we'll think if there is a way to find a separable piece there for you to tackle. It is likely to take couple of weeks, so doing the other tasks on the list that are separable would be a great option for now.
> 
> I apologize for not stating these complexities up front, but I thought that by the time you start doing VCS integration, we will already have the definition of the workspace.

Thank you for the information Pavel. We will look forward for these changes to land first.