[jitsi-dev] Image replacement for chat panel


#1

I made some changes to Jitsi so that it replaces image URLs even if they don't end with an image extension (.jpg, etc.). Many image URLs on the internet don't include the image extension. Here's an example:
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcScsV2toZf7yJUI-XWYR_Ge5LGaSgsveGrfJV1tXN2rE1p3wzga

I don't think that just matching on extensions is an accurate way of determining whether an image replacement should take place. What I'm doing instead is pulling in the content-type for the URL, and if it matches known image content types, the image replacement happens.

Another change I made is to make the images aspect ratio correct. Currently, Jitsi just forces the images to 120x90, I think, and this ends up distorting most images that you link. Due to the HTML renderer that the chat panel uses, it looks like we have to define a specific width and height. So, I'm reading the image width and height as well as the content type, then I fix the replacement image HTML width at 320 and make the height proportional.

My friends and I feel that it's a pretty nice improvement to the experience of chatting in Jitsi. Do you think there's any chance at getting this added to Jitsi? My implementation is hacky because I had to change the image replacement regular expression to basically allow for any URL and then add in an additional check to see whether the URL has an image content-type. It's not the most efficient, either, because you end up downloading the image twice. I can submit my implementation, but I'm sure there's a more elegant solution for people who know the Jitsi codebase well. The core problem, though, is that Jitsi is currently using a regular expression to determine whether the image replacement should take place, and that just isn't enough information to really determine whether a URL is an image without grabbing the content type because image URLs can be pretty much any arbitrary URL.

Thanks,
Joseph Caporale


#2

Hey Joseph,

I made some changes to Jitsi so that it replaces image URLs even if they
don't end with an image extension (.jpg, etc.). Many image URLs on the
internet don't include the image extension. Here's an example:
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcScsV2toZf7yJUI-XWYR_Ge5LGaSgsveGrfJV1tXN2rE1p3wzga

I don't think that just matching on extensions is an accurate way of
determining whether an image replacement should take place.

No, indeed it isn't. It was the simplest and the least painful though.

What I'm
doing instead is pulling in the content-type for the URL, and if it
matches known image content types, the image replacement happens.

This sounds like a reliable way but it means that we'd basically need to go and GET every single link that people exchange through Jitsi. Not sure if people will be happy about it.

Another change I made is to make the images aspect ratio correct.
Currently, Jitsi just forces the images to 120x90, I think, and this
ends up distorting most images that you link. Due to the HTML renderer
that the chat panel uses, it looks like we have to define a specific
width and height.

That's neat. We'd be happy to take a patch on this:

https://jitsi.org/Documentation/FAQ#patch

(separately from the first issue).

So, I'm reading the image width and height as well as
the content type, then I fix the replacement image HTML width at 320 and
make the height proportional.

My friends and I feel that it's a pretty nice improvement to the
experience of chatting in Jitsi. Do you think there's any chance at
getting this added to Jitsi?

Possibly yes. We'd need to take care of the privacy aspect though (which would imply having it turned off by default).

My implementation is hacky because I had to
change the image replacement regular expression to basically allow for
any URL and then add in an additional check to see whether the URL has
an image content-type. It's not the most efficient, either, because you
end up downloading the image twice.

Which could be an issue if the link turns out to be a 10GB file. This would also need to be resolved.

Isn't there a way to just get the Content-Lenght and Content-Type headers without downloading the whole thing?

I can submit my implementation, but
I'm sure there's a more elegant solution for people who know the Jitsi
codebase well.

Well, it has to start somewhere. I don't think anyone else is currently working on this. I do know Hristo had looked at the size issue so maybe he'll chime in.

Emil

···

On 10.09.13, 01:11, Joseph Caporale wrote:

The core problem, though, is that Jitsi is currently
using a regular expression to determine whether the image replacement
should take place, and that just isn't enough information to really
determine whether a URL is an image without grabbing the content type
because image URLs can be pretty much any arbitrary URL.

Thanks,
Joseph Caporale

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

Hey guys,

Here are a couple of things that might be useful for this:

Most of the web sites should implement the HEAD http method, which allows
you to do exactly that - get the content type, content length, etc. This
sounds like a good way to avoid downloading huge files that are not photos.
It will also solve the privacy issue to some extent.

About downloading things twice:
First, if the HEAD thing works out OK, this will be a much smaller problem.
Either way, we could use a data URI [1] for the images to avoid downloading
them twice (although this could affect memory usage a bit, I'm not sure
it's anything serious).

And a bit off-topic - Emil, have you guys considered using the Github pull
requests instead of exchanging patches via email? It's not perfect, but I
think it's much cleaner - you can view the whole patch online, comment on
it and request changes, and then the developer can fix the issues in the
same pull request, etc.

Cheers,
Ivan

[1] http://en.wikipedia.org/wiki/Data_URI_scheme

···

On Tue, Sep 10, 2013 at 11:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Joseph,

On 10.09.13, 01:11, Joseph Caporale wrote:

I made some changes to Jitsi so that it replaces image URLs even if they
don't end with an image extension (.jpg, etc.). Many image URLs on the
internet don't include the image extension. Here's an example:
https://encrypted-tbn0.gstatic.com/images?q=tbn:
ANd9GcScsV2toZf7yJUI-XWYR_**Ge5LGaSgsveGrfJV1tXN2rE1p3wzga<https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcScsV2toZf7yJUI-XWYR_Ge5LGaSgsveGrfJV1tXN2rE1p3wzga>

I don't think that just matching on extensions is an accurate way of
determining whether an image replacement should take place.

No, indeed it isn't. It was the simplest and the least painful though.

What I'm

doing instead is pulling in the content-type for the URL, and if it
matches known image content types, the image replacement happens.

This sounds like a reliable way but it means that we'd basically need to
go and GET every single link that people exchange through Jitsi. Not sure
if people will be happy about it.

Another change I made is to make the images aspect ratio correct.

Currently, Jitsi just forces the images to 120x90, I think, and this
ends up distorting most images that you link. Due to the HTML renderer
that the chat panel uses, it looks like we have to define a specific
width and height.

That's neat. We'd be happy to take a patch on this:

https://jitsi.org/**Documentation/FAQ#patch<https://jitsi.org/Documentation/FAQ#patch>

(separately from the first issue).

So, I'm reading the image width and height as well as

the content type, then I fix the replacement image HTML width at 320 and
make the height proportional.

My friends and I feel that it's a pretty nice improvement to the
experience of chatting in Jitsi. Do you think there's any chance at
getting this added to Jitsi?

Possibly yes. We'd need to take care of the privacy aspect though (which
would imply having it turned off by default).

  My implementation is hacky because I had to

change the image replacement regular expression to basically allow for
any URL and then add in an additional check to see whether the URL has
an image content-type. It's not the most efficient, either, because you
end up downloading the image twice.

Which could be an issue if the link turns out to be a 10GB file. This
would also need to be resolved.

Isn't there a way to just get the Content-Lenght and Content-Type headers
without downloading the whole thing?

I can submit my implementation, but

I'm sure there's a more elegant solution for people who know the Jitsi
codebase well.

Well, it has to start somewhere. I don't think anyone else is currently
working on this. I do know Hristo had looked at the size issue so maybe
he'll chime in.

Emil

The core problem, though, is that Jitsi is currently

using a regular expression to determine whether the image replacement
should take place, and that just isn't enough information to really
determine whether a URL is an image without grabbing the content type
because image URLs can be pretty much any arbitrary URL.

Thanks,
Joseph Caporale

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>

--
https://jitsi.org

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>


#4

Hello,

I think we support image preview not only for http, but for ftp also.

We can check the size of the image without downloading it using ftp by
sending a SIZE command to the ftp server.

I made a patch that checks the image size before downloading the image but
it isn't applied yet.

I have used HttpURLConnection.getContentLengthLong() method to get the size
of the image without downloading it for the http protocol. As I remember I
tested it and the method doesn't download the image.

Regards,
Hristo.

···

On Tue, Sep 10, 2013 at 12:45 PM, Ivan Vergiliev <ivan.vergiliev@gmail.com>wrote:

Hey guys,

Here are a couple of things that might be useful for this:

Most of the web sites should implement the HEAD http method, which allows
you to do exactly that - get the content type, content length, etc. This
sounds like a good way to avoid downloading huge files that are not photos.
It will also solve the privacy issue to some extent.

About downloading things twice:
First, if the HEAD thing works out OK, this will be a much smaller
problem. Either way, we could use a data URI [1] for the images to avoid
downloading them twice (although this could affect memory usage a bit, I'm
not sure it's anything serious).

And a bit off-topic - Emil, have you guys considered using the Github pull
requests instead of exchanging patches via email? It's not perfect, but I
think it's much cleaner - you can view the whole patch online, comment on
it and request changes, and then the developer can fix the issues in the
same pull request, etc.

Cheers,
Ivan

[1] http://en.wikipedia.org/wiki/Data_URI_scheme

On Tue, Sep 10, 2013 at 11:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Joseph,

On 10.09.13, 01:11, Joseph Caporale wrote:

I made some changes to Jitsi so that it replaces image URLs even if they
don't end with an image extension (.jpg, etc.). Many image URLs on the
internet don't include the image extension. Here's an example:
https://encrypted-tbn0.gstatic.com/images?q=tbn:
ANd9GcScsV2toZf7yJUI-XWYR_**Ge5LGaSgsveGrfJV1tXN2rE1p3wzga<https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcScsV2toZf7yJUI-XWYR_Ge5LGaSgsveGrfJV1tXN2rE1p3wzga>

I don't think that just matching on extensions is an accurate way of
determining whether an image replacement should take place.

No, indeed it isn't. It was the simplest and the least painful though.

What I'm

doing instead is pulling in the content-type for the URL, and if it
matches known image content types, the image replacement happens.

This sounds like a reliable way but it means that we'd basically need to
go and GET every single link that people exchange through Jitsi. Not sure
if people will be happy about it.

Another change I made is to make the images aspect ratio correct.

Currently, Jitsi just forces the images to 120x90, I think, and this
ends up distorting most images that you link. Due to the HTML renderer
that the chat panel uses, it looks like we have to define a specific
width and height.

That's neat. We'd be happy to take a patch on this:

https://jitsi.org/**Documentation/FAQ#patch<https://jitsi.org/Documentation/FAQ#patch>

(separately from the first issue).

So, I'm reading the image width and height as well as

the content type, then I fix the replacement image HTML width at 320 and
make the height proportional.

My friends and I feel that it's a pretty nice improvement to the
experience of chatting in Jitsi. Do you think there's any chance at
getting this added to Jitsi?

Possibly yes. We'd need to take care of the privacy aspect though (which
would imply having it turned off by default).

  My implementation is hacky because I had to

change the image replacement regular expression to basically allow for
any URL and then add in an additional check to see whether the URL has
an image content-type. It's not the most efficient, either, because you
end up downloading the image twice.

Which could be an issue if the link turns out to be a 10GB file. This
would also need to be resolved.

Isn't there a way to just get the Content-Lenght and Content-Type headers
without downloading the whole thing?

I can submit my implementation, but

I'm sure there's a more elegant solution for people who know the Jitsi
codebase well.

Well, it has to start somewhere. I don't think anyone else is currently
working on this. I do know Hristo had looked at the size issue so maybe
he'll chime in.

Emil

The core problem, though, is that Jitsi is currently

using a regular expression to determine whether the image replacement
should take place, and that just isn't enough information to really
determine whether a URL is an image without grabbing the content type
because image URLs can be pretty much any arbitrary URL.

Thanks,
Joseph Caporale

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>

--
https://jitsi.org

______________________________**_________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/dev<http://lists.jitsi.org/mailman/listinfo/dev>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev