5 ms·

It's open-source, if you rely on it, fork it and fix it yourself.

by phaed 10y ago

JoshGlazebrook 10y ago
That still doesn't make it reliable. If it's known the DOM changes regularly and breaks this api library, then why bother in the first place? Sure you can fix it yourself, but why not avoid the hassle and use something standard that doesn't break as much. If it's acceptable that it breaks often then it's fine to use, but if you're expecting reliability, then no.
- alooPotato 10y ago
  see my comment to your sibling...
seibelj 10y ago
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.
- nathancahill 10y ago
  Which Gmail addon did you work on?
  - seibelj 10y ago
    An MVP for a startup we never got any traction on :)
- alooPotato 10y ago
  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.
  - tyre 10y ago
    We use your InboxSDK and it is wonderful. Made development of an extension delightful, especially compared with the workflow around Outlook Add-ons and Wordpress Plugins. By the way, there's a real opportunity to own the content side of gmail development. Articles on getting up and running, like building a basic Rapportive clone, would be incredible.
  - xigency 10y ago
    How can you automatically update the SDK?
    - alooPotato 10y ago
      The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
      - chrissnell 10y ago
        So you don't automatically update the library. You only automatically distribute your manually-updated library.
      - alooPotato 10y ago
        The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again. EDIT: we have automated systems that help with this though making our turnaround time incredibly fast. We also see the changes to gmail before 99% of users so usually our updates are out before users even refresh to get the new version of gmail
  - zkhalique 10y ago
    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?

It's open-source, if you rely on it, fork it and fix it yourself.

by phaed 10y ago

It's open-source, if you rely on it, fork it and fix it yourself.

That still doesn't make it reliable. If it's known the DOM changes regularly and breaks this api library, then why bother in the first place? Sure you can fix it yourself, but why not avoid the hassle and use something standard that doesn't break as much. If it's acceptable that it breaks often then it's fine to use, but if you're expecting reliability, then no.

alooPotato 10y ago
see my comment to your sibling...

seibelj 10y ago

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.

nathancahill 10y ago
Which Gmail addon did you work on?
- seibelj 10y ago
  An MVP for a startup we never got any traction on :)
alooPotato 10y ago
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.
- tyre 10y ago
  We use your InboxSDK and it is wonderful. Made development of an extension delightful, especially compared with the workflow around Outlook Add-ons and Wordpress Plugins. By the way, there's a real opportunity to own the content side of gmail development. Articles on getting up and running, like building a basic Rapportive clone, would be incredible.
- xigency 10y ago
  How can you automatically update the SDK?
  - alooPotato 10y ago
    The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again.
    - chrissnell 10y ago
      So you don't automatically update the library. You only automatically distribute your manually-updated library.
    - alooPotato 10y ago
      The library is remote loaded at runtime. We update it on our servers and the next time the user refreshes gmail, the library gets pulled down again. EDIT: we have automated systems that help with this though making our turnaround time incredibly fast. We also see the changes to gmail before 99% of users so usually our updates are out before users even refresh to get the new version of gmail
- zkhalique 10y ago
  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?