Function: DataUri()

[Alan Williamson (aw2.0 ltd)]

How do we feel about adding an "official" top-level function to do
embedded images in pages?

http://en.wikipedia.org/wiki/Data_URI_scheme

PHP has a function to do this.

[Peter Boughton]

I think I'd favour an extra arg for toBase64.

Either an explicit prefix="data:image/png;base64," or an automatc AsUrl=true

If it was a new function, I'd probably be in favour of toBase64Uri

Unless there are different (non-Base64) ways of doing this, in which
case I'd say toDataUri ( data , 'base64' ) or similar.

[Alan Williamson (aw2.0 ltd)]

;) okay so you proposed __3__ different solutions there.

i favour: toDataUri ( data, 'base64' )

where data could be: URL, pathname, or a binary data type.

[larryclyons]

Looking at the wikipedia entry, that's a fair amount of code, for
instance to produce a small red dot,

<img src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />

I cannot see the advantage over
<img src="image/smallRedDot.png" alt="Red Dot" />

Maybe I am missing something.

regards,
larry

On Sep 9, 9:56 am, "Alan Williamson (aw2.0 ltd)" <a...@aw20.co.uk>
wrote:

[Todd Rafferty]

I can. Self contained HTML demo pages, etc. Pass someone a single index.html and no need to zip up files to go along with it, etc.

The Railo admin is served from a .ra file and because of that there can't be any image files and such, everything has to be a .cfm / .cfc file -- this could potentially resolve an issue of having to convert everything over to a .cfm / .cfc file.

--
CFML Conventional Wisdom
 http://groups.google.com/group/cfml-conventional-wisdom?hl=en?hl=en

[Alan Williamson]

It also reduces load on the server in terms of connections. Not advocating its a wide spread use and suddenly you stop serving files. Good for captcha type systems.

--
aw2.0 ltd www.aw20.co.uk

---

From: Todd Rafferty <web...@gmail.com>

Sender: cfml-convent...@googlegroups.com

Date: Thu, 9 Sep 2010 21:10:11 -0400

To: <cfml-convent...@googlegroups.com>

ReplyTo: cfml-convent...@googlegroups.com

Subject: Re: [CFML] Re: Function: DataUri()

[Peter J. Farrell]

larryclyons said the following on 09/09/2010 07:59 PM:

Looking at the wikipedia entry, that's a fair amount of code, for
instance to produce a small red dot,

<img src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />

I cannot see the advantage over
<img src="image/smallRedDot.png" alt="Red Dot" />

Maybe I am missing something.

  

Actually it's a performance technique for making the front end of your website perform better. Approximately 80% of the total time of a request is fetching assets (whereas 20% is server processing time).  This includes HTTPs calls and DNS lookups. For small stuff like your "dot", you can make them inline via the <img> tag or even in your CSS files. This reduces the total number of assets to be fetched (most browser limit requests to 2 per domain at a time), reduces the an HTTP call and possible a DNS lookup (say the image is asset01.example.com and not example.com). To quote the Yahoo Exceptional Performance Rules:

http://developer.yahoo.com/performance/rules.html#num_http

Inline images use the data: URL scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages. Inline images are not yet supported across all major browsers.

Reducing the number of HTTP requests in your page is the place to start. This is the most important guideline for improving performance for first time visitors. As described in Tenni Theurer's blog post Browser Cache Usage - Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these first time visitors is key to a better user experience.

HTH,
.pjf

[denstar]

On Thu, Sep 9, 2010 at 8:18 AM, Alan Williamson (aw2.0 ltd) wrote:
> ;) okay so you proposed __3__ different solutions there.
>
> i favour:   toDataUri ( data, 'base64' )
>
> where data could be: URL, pathname, or a binary data type.

I like it, but can it be anything besides base64? Maybe it should be
mime type or something as the second argument, overriding whatever the
automatic type check returns?

:Den

--
The world is all a carcass and vanity, The shadow of a shadow, a play
And in one word, just nothing.
Michel de Montaigne

[Peter J. Farrell]

denstar said the following on 09/09/2010 11:29 PM:

>
> I like it, but can it be anything besides base64? Maybe it should be
> mime type or something as the second argument, overriding whatever the
> automatic type check returns?
>

Aren't all toDataUri going to be encoded in Base64 like 99% of the
time? I doubt you'll want them in ASCII very often.

I propose this:

toDataUri(data, mimeType:auto, encoding:base64)

The mime-type is auto discovered -- I don't expect any magic numbers
type of checking. A straight "general" file extension to mime-type map
is fine with me. By default, everything is base64 encoded.

Most of the time I bet this is what you'd see:

toDateUri(data)

.pjf

[denstar]

On Thu, Sep 9, 2010 at 10:52 PM, Peter J. Farrell wrote:
> denstar said the following on 09/09/2010 11:29 PM:
>>
>> I like it, but can it be anything besides base64?  Maybe it should be
>> mime type or something as the second argument, overriding whatever the
>> automatic type check returns?
>>
> Aren't all toDataUri going to be encoded in Base64 like 99% of the
> time?  I doubt you'll want them in ASCII very often.

Exactamundo!

> I propose this:
>
> toDataUri(data, mimeType:auto, encoding:base64)
>
> The mime-type is auto discovered -- I don't expect any magic numbers
> type of checking.  A straight "general" file extension to mime-type map
> is fine with me.  By default, everything is base64 encoded.

Yuppers. If you had to add the second param, it would be when passing
pure data, vs a file path.

:Den

--
The worst of my actions or conditions seem not so ugly unto me as I
find it both ugly and base not to dare to avouch for them.
Michel de Montaigne

[denstar]

On Thu, Sep 9, 2010 at 11:44 PM, denstar wrote:
>
> Yuppers.  If you had to add the second param, it would be when passing
> pure data, vs a file path.

Assuming you can pass pure data. :)

Perhaps an encoding attribute would be needed, or would that be picked
up from the context?

:Den

--
There are some defeats more triumphant than victories.
Michel de Montaigne

[Markus Wollny]

It's about reducing the number of HTTP requests, as each one imposes an overhead of usually at least 50ms on the overall page delivery time. DataURI thus makes a lot of sense, especially when used in cacheable external CSS. Remember that even if a resource is cached, there may be a request to see if it's still fresh - answer is all header, no payload if it is, but it's still a request roundtrip.

[Alan Williamson]

Yeah, we know the type of data by the time the function gets called so it would be very easy to make that decision.


--
aw2.0 ltd www.aw20.co.uk

-----Original Message-----
From: denstar <vallia...@gmail.com>
Sender: cfml-convent...@googlegroups.com

[Andrew Penhorwood]

> I propose this:
>
> toDataUri(data, mimeType:auto, encoding:base64)
>

This makes the most sense to me since http://tools.ietf.org/html/rfc2397
refers to ACSII as well as base64 encoding and other MIME types.

Andrew Penhorwood