Earlier quoted context omitted.
The snark was uncalled for, so is drawing noses on emoticons.
Snark is always called for, always appropriate! edit: you downvoters are lame. What a bunch of wimps
Gmail.js – JavaScript API for Gmail
41–50 of 52 posts
Re: Gmail.js – JavaScript API for Gmail
#42We used this for a project before, just be aware that the DOM changes regularly for gmail, and if an API you rely on breaks you will be SOL until someone fixes it.
Agree. I did a gmail plugin before gmail.js came out. You kind have the same problem if you are the only one using your custom lib and you dont have a huge army of others who could fix it. And it's… so… much… more exhausting
Re: Gmail.js – JavaScript API for Gmail
#43Re: Gmail.js – JavaScript API for Gmail
#44I've written a couple of articles on the proper Gmail API, why doesn't this just use that instead of scraping the DOM? https://www.sitepoint.com/mastering-your-inbox-with-gmail-ja... https://www.sitepoint.com/sending-emails-gmail-javascript-ap...
Re: Gmail.js – JavaScript API for Gmail
#45Earlier quoted context omitted.
The snark was uncalled for, so is drawing noses on emoticons.
Snark is always called for, always appropriate! edit: you downvoters are lame. What a bunch of wimps
edit: You downvoters of my comment, however, are lame!
Re: Gmail.js – JavaScript API for Gmail
#46Earlier quoted context omitted.
The issue is that gmail will update at anytime, without warning, so there will always be a period when your service will break. And you need to have unit tests running often to figure out when it breaks, and have a dev on call 24/7 to ensure a speedy fix. This is a universal problem with extensions targeting website DOM's, but worse if you have an SaaS product that has an SLA.
Founder of Streak here (we make the InboxSDK) - this is one area where we take a slightly different approach than Gmail.js. We host our SDK and you remotely load it at runtime. The benefit is that we detect breakages due to gmail and automatically update the SDK. Your users just need to refresh gmail to load your extension and the latest SDK which is compatible with any changes Gmail makes.
Re: Gmail.js – JavaScript API for Gmail
#47Earlier quoted context omitted.
Agree. I did a gmail plugin before gmail.js came out. You kind have the same problem if you are the only one using your custom lib and you dont have a huge army of others who could fix it. And it's… so… much… more exhausting
It seems like you might be able to come up with a way to auto-generate these selectors based on known content on the page. ie, find the thing that has this text in it and use that as the selector from now on.
back then we even ended up using surprisingly complex structures that actually are close to what you describe but clientside. as in: we didnt rely on classnames but often on positions next to some text.
``` find(SomeTitle).parent.parent.find(p[something]).text ```
Re: Gmail.js – JavaScript API for Gmail
#48I want to thank the author. Like many users, to repeat this project entirely on my own would be a nightmare. The GMail HTML source produced from the server is "minified". Random, meaningless class and id names. Author took on the burden and made Gmail more accessible for browser extension/add-on. I implemented a FireFox addon (for accessibility purpose for my senior thesis) using Gmail.js. Furthermore, the code is ve…
Re: Gmail.js – JavaScript API for Gmail
#49Earlier quoted context omitted.
Founder of Streak here (we make the InboxSDK) - this is one area where we take a slightly different approach than Gmail.js. We host our SDK and you remotely load it at runtime. The benefit is that we detect breakages due to gmail and automatically update the SDK. Your users just need to refresh gmail to load your extension and the latest SDK which is compatible with any changes Gmail makes.
InboxSDK looks awesome. I took a look at it several months ago, and we want to build something on GMail. We're a little concerned about the licensing and availability of the library, though. Is it possible that a month from now you decide that we're competing with something you want to do, and stop serving the library for our app? What would be our recourse then?
In general though, we treat the SDK as its own product and have several competitors to Streak using it. We have millions of end users using apps built on the SDK from major companies (Dropbox, Hubspot, etc) so we're pretty careful with our terms.
The main goal is to retain the ability to maintain compatibility between different extensions being run by the same user and being able to respond quickly to changes in Gmail.