Implemented image attachments

[bdc34]

Modifying the html to use cid's to the attachements Adding note to README that BeautifulSoup4 is required Changing r2e to use python3

Signed-off-by: Brian Caruso briancaruso@gmail.com

[bdc34]

There is still a lot to do. Need to handle requests for bad host names. Need to skip getting images when doing a run --no-send

[wking]

On Fri, Aug 09, 2013 at 03:52:14PM -0700, Brian Caruso wrote:

There is still a lot to do. Need to handle requests for bad host names. Need to skip getting images when doing a run --no-send

Sorry about the delayed response. This looks useful, but I think you should drop the shebang change in r2e (shebangs are automatically adjusted to match your system when you install a package).

I don't understand the cid:{}{} formatting. Is that just so you can preserve the path part of the origin URL in your cid: replacements?

I also think we should just fetch the linked reference (regardless of guessed MIME type) and extract the MIME type from the response headers.

Do you want to reroll this? Alternatively, do you mind if I drop the r2e shebang change and keep the rest, fixing it up with subsequent commits?

[bdc34]

I would not mind if you drop the shebang.

I was including the path in attempt to avoid multiple attachments if a file was included several times in the same email/item. I needed a cid and I thought I'd start with that. I hoped to go beck and try to set it up to avoid redundant attachments. On Sep 28, 2013 5:07 PM, "W. Trevor King" notifications@github.com wrote:

On Fri, Aug 09, 2013 at 03:52:14PM -0700, Brian Caruso wrote:

There is still a lot to do. Need to handle requests for bad host names. Need to skip getting images when doing a run --no-send

Sorry about the delayed response. This looks useful, but I think you should drop the shebang change in r2e (shebangs are automatically adjusted to match your system when you install a package).

I don't understand the cid:{}{} formatting. Is that just so you can preserve the path part of the origin URL in your cid: replacements?

I also think we should just fetch the linked reference (regardless of guessed MIME type) and extract the MIME type from the response headers.

Do you want to reroll this? Alternatively, do you mind if I drop the r2e shebang change and keep the rest, fixing it up with subsequent commits?

— Reply to this email directly or view it on GitHubhttps://github.com/wking/rss2email/pull/15#issuecomment-25308506 .

[wking]

On Mon, Sep 30, 2013 at 06:51:07AM -0700, Brian Caruso wrote:

I was including the path in attempt to avoid multiple attachments if a file was included several times in the same email/item. I needed a cid and I thought I'd start with that. I hoped to go beck and try to set it up to avoid redundant attachments.

Maybe the best way to do this is to use the previous cid: formatting, but have Feed._process_entry_content manage a cache dict mapping previously seen URLs to cids. The Feed._get_reference could check if new paths were in the feed, if so, it would return (if self.include_references is True):

(, None)

and we would only attach a new part if we had a new part to attach. I dunno how clear that sounds, so I'll try and work up and example patch sometime today.

[bdc34]

It looks like I have two additional commits that I didn't push. I'm pushing them now.

It looks like the older of the two is 824f9633 and adds a try when reading the image URL request result.

The new is a13d7e135 and adds a bunch of headers to the attached image part and has a different way the CID is created. This commit was an attempt to get android's gmail client to work with CIDs but it didn't end up working well.

On Mon, Sep 30, 2013 at 12:01 PM, W. Trevor King notifications@github.comwrote:

Maybe the best way to do this is to use the previous cid: formatting, but have Feed._process_entry_content manage a cache dict mapping previously seen URLs to cids. The Feed._get_reference could check if new paths were in the feed, if so, it would return (if self.include_references is True):

(, None)

and we would only attach a new part if we had a new part to attach. I dunno how clear that sounds, so I'll try and work up and example patch sometime today.

That sounds great. I was hoping to do something like that but was sidetracked.

[Ekleog]

@bdc34 The rss2email repository has moved to https://github.com/rss2email/rss2email following maintainership changes. This PR appears WIP and not ready to be merged for now, plus it apparently points to a feature branch of this repo, and it looks like I can't just create a PR from your PR to there myself (I guess due to the two not being forks-according-to-github). Would you mind sending your PR over there if you think it's useful?

[bdc34]

Léo

Sorry, I do not think it will be useful anymore. It would be better to start this from scratch.

Thanks for your work, Brian Caruso Repository Developer Cornell University Library t 607-255-1790

---

From: Léo Gaspard notifications@github.com Sent: Monday, April 15, 2019 11:00:02 AM To: wking/rss2email Cc: Brian D. Caruso; Mention Subject: Re: [wking/rss2email] Implemented image attachments (#15)

@bdc34https://github.com/bdc34 The rss2email repository has moved to https://github.com/rss2email/rss2email following maintainership changes. This PR appears WIP and not ready to be merged for now, plus it apparently points to a feature branch of this repo, and it looks like I can't just create a PR from your PR to there myself (I guess due to the two not being forks-according-to-github). Would you mind sending your PR over there if you think it's useful?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/wking/rss2email/pull/15#issuecomment-483288364, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAGUDCZqnOD7SXyjsiBWDYyGC6pyvMRks5vhJPygaJpZM4A5Cnv.

[Ekleog]

OK, thank you for your feedback! :)

[bdc34]

Closed due to lack of interest.