On Tue, Apr 2, 2013 at 6:57 PM, Joseph Pecoraro wrote:
> I see you are both the editors of the Source Map Revision 3 Proposal spec
> 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
> 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
> 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
> 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?
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
> - Joe