[standards-jig] jep-0071 img tag
richard at dobson-i.net
Thu Feb 12 10:36:53 UTC 2004
> > Anyway IMO a mobile client should not be wasting bandwidth trying to
> > images into messages anyway considering how expensive it is, certainly
> > in the UK anyway.
> 'Should' ofcourse won't cut it out there ;) The users want it. Why do
> you think half of the phones have a built in camera nowadays?
Its got nothing to do with users wanting it, anyone with any real knowledge
of this would know that (its the manufacturers trying to find the next SMS,
i.e. the next extremely profitable mobile phone fad, remember how much of a
flop WAP has been, lots of people have WAP capable phones but hardly anyone
actually uses it very often if ever), I know lots of people with camera
phones but hardly any of them actually use the camera at all (partly because
its so expensive, partly because they dont really see the point, the same
thing has been experienced with 3G here, no one can see the point of it),
the primary reason these people got their smartphones was because they have
cool downloadable games (or just trying to keep up to date with their mates,
competion between friends of who has the better phone has been a significant
factor over here for people upgrading their phones, and again it often has
nothing to do with the features in the phone, people just dont want to be
seen as having an "ancient" phone), the camera is just something that comes
standard with these type of smartphones.
> I'm currently working on a J2ME client that is able to send messages
> with embedded photos from the built in camera to a home device. It's
> limited to a specific set of hardware so I'm just BASE64-ing the image
> and including it in the message itself.
Well IMO if you are not doing it in a standardised way then it seems
pointless you bothering to do that as no one other than users of your client
will see the images, also I wouldnt be surprised if server admins started to
block messages with your extension in as some have with IBB.
> The main problem with the current proposal is the fact that both clients
> have to be online at the same time. Most mobile clients are not online
> 24/7 so if I send a message while the recipient is offline I'm out of
> luck. That's not acceptable in the project that I'm working on and
> therefore I'm using inline images.
Simple then you upload the image to a common data store (e.g. an HTTP server
or your public storage), forcing potensially large images to be stored
offline is going to do nothing other than get server admins to modify their
servers to either block your extended messages or stop them from being
stored offline which kind of defeats your efforts. The main problem with
attaching the file data directly which is why we removed it was the fact
that people need to choice as to wether to recieve the data or not, and to
do that you really need some way for the receiver to actively request the
data rather than it being forcibly pushed onto people which if it is large
can seriously hamper their use of IM, personally I would be extremely
annoyed if I was interrupted talking to someone just because you decided to
send me a 100k image you just snapped on your smart phone. Also if I was
offline and their was a quota on my offline storage (which I expect more
people will implement in servers soon enough), I would be extremely annoyed
if your large image in my offline storage caused an important message from a
friend to be dropped due to my offline storage being full because of your
> Maybe this is something to take into account while working on
We already have and rejected it because it was determined to cause far more
problems than it had benefits.
More information about the Standards