[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

Richard Dobson wrote:
> 
> ----- Original Message -----
> From: "Dave" <dave at dave.tj>
> To: <jdev at jabber.org>
> Sent: Tuesday, April 23, 2002 9:47 PM
> Subject: Re: [JDEV] Emoticons: guidelines
> 
> > > any means it is part of the wap standards, I said all of this because
> your
> > I happen to hate the WAP standards, but that's neither here nor there;
> > they _are_ pretty much standardized, and there's not much I can do about
> > it at this point: just being sour about it is silly.  However, I would
> > insist that any device that supports images be able to read PNG format
> > files, because standards are good, and should therefore be supported.
> 
> Well insist all you want, the fact is WAP phones do not support .png, deal
> with it, or go and argue this with Nokia (and the other mobile
> manufacturers). Also were are you getting the impression from that PNG is
> THE universal format suitable for all devices, why not let people use
> formats most suited to the environment they are designed for.
If your WAP phone can run a Jabber client, it can run a
PNG->some-proprietary-image-format converter just as easily.

> 
> > > method assumes that the receiving client (in this case a WAP phone)
> > > definately supports the image format you are sending it, and if you are
> > > sending .png, .gif, or .jpg a WAP phone would be unable to support it,
> this
> > > is YAP (yet another problem) with your system.
> > Obviously, there's a cruel little HTTP-based solution you can use
> > if you're fundamentally opposed to standard image formats, involving
> > client capability negotiation (totally compatible with HTTP/1.0 and 1.1).
> > Briefly, here's how it works: when your client sends a request to an HTTP
> > server, it normally sends an HTTP-Accept header, listing all the MIME
> > types that your client understands.  There's nothing stopping the server
> > from sending a version of the image that's in - or even converting an
> > image on-the-fly from whatever format it's stored in into - some format
> > that the client supports.
> > Most popular web servers support client capability negotiation.
> > (A variation on the same is often used to decide what language to send
> > a document in, BTW.)
> 
> Urm riggghttt, so now you are proposing that we write stuff for the
> webserver hosting the images, you really are making a mountain out of a mole
> hill over this arnt you,
Fortunately, that mountain has already been scaled plenty of times by
others, and many solutions already exist - unless you object to GPLed
software ;-P

> emoticons do not have to be this complicated.
I'd consider regexp-matching far more complicated for an XML application
than simply picking out XML elements (be they _real_ XML emoticons or
HTML IMG tags).

> Also
> the capability mechanism you suggest is not compatible with your previous
> postings that indicate clients should be requesting PNG files,
The "capability mechanism" I suggest was a direct response to your concern
about open standards taking over the world, and it _is_ compatible with
the request for clients to use PNG files, even if you name your images
with a .png suffix.  (GIF images can have a .png extension, and if the
correct Content-type header is sent, your web browser will actually open
them as GIF images.)

> it is part of
> the HTTP spec im sure that if you request a particular document of a
> particular format that should be send to the client not a completely
> different format file.
You don't request the format in the filename.  I've seen images with
a .html extension, and movies with a .cgi extension.  Not only that,
but Apache makes it rather easy to take advantage of that capability ;-)

You request the format in the HTTP-MIME-Accept header of your HTTP
request, by listing your preferred formats.  The Web server then decides
what format to send your way based on that list.  (It may make sense to
give our images a format-agnostic extension (.img, maybe? ...or maybe
no extension) in order to keep others from wondering how their cell
phones suddenly support PNG files, but there's no need from a technical
perspective.)

> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>