4 ms·

The Pipes/IFTTT concept screams for a more open solution, it's too important to be proprietary. I'm always frustrated when I want to use IFTTT but they don't su

The Pipes/IFTTT concept screams for a more open solution, it's too important to be proprietary. I'm always frustrated when I want to use IFTTT but they don't support the services I need. A simple protocol based on HTTP, JSON, and WebHooks could be pretty slick.

johns 14y ago
The protocol only gets you so far though. I'd argue that our (I work at IFTTT) value exists at a level above that. I would love a standard though, it would make my job waayyy easier.
sneak 14y ago
It would be nice if someone would make a painfully simple interface (a la the "requests" python module) for doing XMPP. Perhaps though XMPP is just too much of a quagmire.
- lurker14 14y ago
  https://developers.google.com/appengine/articles/using_xmpp https://developers.google.com/appengine/articles/using_xmpp ?
tfb 14y ago
I've actually been working on exactly this (but considerably more powerful and in-depth than Pipes/IFTTT) for quite some time now (almost 2 years, on and off). It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned). Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first. From a technical standpoint, this is currently where I'm at with it: - Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion - Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another - All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing - Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time - Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each - Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data - Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;) - Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code - Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that - Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app - Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com http://loggur.com
- sdepablos 14y ago
  Sounds interesting. I'll give it a try asap you release it.
ldng 14y ago
My memory is fuzzy about this but IIRC some folks from the Gnome Conduit project launched or talked about launching a web version of it. Not sure though. Sadly, the project seems dormant. Could be an interesting starting point anyway.
wslh 14y ago
The approach that I am working on is a web orchestration language. You can write s-expressions specifying the dataflow. Obviously alternative frontends can be built to output the s-expression. I published more information on: - Ideas: Egont, A Web Orchestration Language: http://blog.databigbang.com/ideas-egont-a-web-orchestration-language/ http://blog.databigbang.com/ideas-egont-a-web-orchestration-... - Egont Part II: http://blog.databigbang.com/egont-part-ii/ http://blog.databigbang.com/egont-part-ii/

johns 14y ago

The protocol only gets you so far though. I'd argue that our (I work at IFTTT) value exists at a level above that. I would love a standard though, it would make my job waayyy easier.

sneak 14y ago

It would be nice if someone would make a painfully simple interface (a la the "requests" python module) for doing XMPP. Perhaps though XMPP is just too much of a quagmire.

lurker14 14y ago
https://developers.google.com/appengine/articles/using_xmpp https://developers.google.com/appengine/articles/using_xmpp ?

tfb 14y ago

I've actually been working on exactly this (but considerably more powerful and in-depth than Pipes/IFTTT) for quite some time now (almost 2 years, on and off). It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned). Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first. From a technical standpoint, this is currently where I'm at with it: - Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion - Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another - All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing - Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time - Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each - Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data - Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;) - Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code - Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that - Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app - Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com http://loggur.com

sdepablos 14y ago
Sounds interesting. I'll give it a try asap you release it.

ldng 14y ago

My memory is fuzzy about this but IIRC some folks from the Gnome Conduit project launched or talked about launching a web version of it. Not sure though. Sadly, the project seems dormant. Could be an interesting starting point anyway.

wslh 14y ago

The approach that I am working on is a web orchestration language. You can write s-expressions specifying the dataflow. Obviously alternative frontends can be built to output the s-expression. I published more information on: - Ideas: Egont, A Web Orchestration Language: http://blog.databigbang.com/ideas-egont-a-web-orchestration-language/ http://blog.databigbang.com/ideas-egont-a-web-orchestration-... - Egont Part II: http://blog.databigbang.com/egont-part-ii/ http://blog.databigbang.com/egont-part-ii/