On Wed, Sep 21, 2011 at 10:43 AM, Stephan Beal <[email protected]>wrote:
> On Wed, Sep 21, 2011 at 5:27 PM, Bill Burdick <[email protected]>wrote: > >> Maybe this is obvious, but a client-side editor could use data-scheme URIs >> to display intermediately edited data before you commit it to Fossil. >> > > It wasn't obvious to me, certainly. Naively i will ask: would that provide > any benefit to that over e.g. base64-encoding to an arbitrary JSON field? > The client has the binary data, so how/where he intends to encode it to > (data URL or in the request JSON) is pretty much up to him. Or am i missing > the point of the proper use of data urls? > The "data" scheme is for actually displaying the binary data, like an image, in a client. Displaying an image in a client is easy if the data came as a stand-alone HTTP document (like as the source of an image element) but if you get an image as part of a stream, like inside a JSON response, and you want to display it in a browser using an image tag or a canvas, you need a URL for that data and that's where the "data" scheme comes in. It allows you to provide that data in-line, rather than as an HTTP request, so you can construct a data URI from the data you got from JSON. That means you can process the image in the client and display the result without having to go back through a server to get it. The data scheme essentially allows a client to emulate a web server for itself (note the mime-type in the example). Bill
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
