From:  John Lenz <concavelenz@gmail.com>
Date:  04 Apr 2013 01:32:09 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: Source Map v3 Proposal - sourcesContent questions

NNTP-Posting-Host:  63.245.216.66

+dev-js-sourcemap@lists.mozilla.org

On Tue, Apr 2, 2013 at 6:57 PM, Joseph Pecoraro  wrote:

> Hey,
>
> I see you are both the editors of the Source Map Revision 3 Proposal spec
> at:
> <
> https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
> >
>
> Comments are disabled, so I'm sending an email.
>
> There was a recent addition of "sourcesContent" to the spec. Although the
> spec doesn't go into detail, it sounds like sourcesContent values are
> either null, or strings containing source text. It seems like that has a
> few drawbacks:
>
> 1. It makes it difficult for SourceMap consumers to determine the MIME
> type of the content. Is it JavaScript? CoffeeScript? Something else
> entirely?
>
> 2. What if an input was not text? Admittedly SourceMaps don't deal with
> binary files in general because it doesn't work with line # conversions,
> but if a resources is generated with a binary file and the binary file is
> listed in the sources list then consumers / debuggers typically fetch it
> anyways.
>
>
> Without sourcesContent, consumers normally make a request (HTTP GET) for
> the source via its resolved URL, and would get MIME type information for
> the resource from the HTTP response.
>

IF the source is available via HTTP there is no need for sourcesContent.


>  Now, with sourcesContent it seems consumers would need to look at the
> file extension of the associated name in the sources list, or make a fuzzy
> determination by scanning the contents. Neither are ideal.
>


> If sourcesContent contents were data URIs, they could contain the mime
> type and contents, e.g. "data:text/javascript,...". I'm open to other
> suggestions as well, this just seems like a simple, potentially backwards
> compatible, change that could be made to the spec and benefit generators
> and consumers of SourceMaps.
>

It seems fragile to have to detect a data URI in place of text.


>
> Is there any desire to improve this portion of the spec? What would need
> to be done to get consensus and make an improvement along these lines?
>
>
Sure.  The end-goal for source maps is to enable tooling for javascript.
 And it is well suited for JS-to-JS translations but for non-JS languages,
there is a lot missing.  The Google Web Toolkit team would like to see
support for identifying heap object.  I've desire "scope" identification.
Microsoft has indicated a desire for source file checksums, etc.  But two
things need to happen (1) there needs to be a concrete proposal (2) the
implementing browser vendors (currently Chrome) need to agree to implement
it.


> - Joe
>