Hacker News Reader

Comment by freehunter | Hacker News Reader

It's somewhat in following with the Unix paradigm; do one thing, do it well.

Not always. Regarding core Unix commands yes (like 'ls', 'cat') but look for example at 'git' which is a real beast.

git is just a facade for the git-* commands.

Not to veer too far from the main discussion, but 'git' isn't just some giant monolithic binary. The 'git' command is a wrapper around a bunch of different, relatively modular binaries. They each even have their own man page. (e.g. 'git push' maps to 'git-push'). Each is just a unique action that can be applied to a common data structure (the git repository).

I know. And still all these different libs are accessible by one UI/route ('git').

Do an ls /usr/libexec/git-core/ (or your operating system's equivalent) some time. The fact that the porcelain exists does not mean that the plumbing does not.

Look closer at git, and you'll see that it's actually a collection of smaller programs (each of the git commands is made as a separate executable before being combined into git)

So when can we do $ camera | fb-photo | facebook | sed 4 | awk ?

Chaining the utilities is the crux of the Unix paradigm, remove that and you're left with individual utilities that are far less powerful than when chained together.

Which is why I said "somewhat". However, you can upload a picture from one app and interact with it in another, so that's... something I guess.

Now. With android intents (ok, not cool as pipes, but the idea is there)

You can do it on iOS as well. You can go from the facebook camera app to the main fb app. (Any app can do this, but the point of the article is fb so i used them as the example)

Is the link between the two apps hardcoded on iOS?

On Android you can have any camera app | any photo editing/filters app | any social network upload where each app is chosen by the user which seems closer to the idea of pipes to me.

Yeah it's something that Facebook would hardcode. Click on this person and instead of doing something here it sends you to that person's profile on their other app.

It isn't like intents on Android, but from the perspective of Facebook it is probably preferable. They don't want you to go to your choice of photo or social network or chat app, they want you to go to their app.

This is a great example; it almost works like UNIX pipes except that each application has to take an explicit action to share its result with the next application in the pipeline. But like UNIX apps that do something anti-social like rewrite the input file (hello, GNU Recode), that can be worked around.

For those of you that don't use Android, the process works like this. You take a picture. The camera app provides a "share" button. You click "share". Then you're presented with a list of all applications that handle photos. So you can share to G+, or email a photo, or run it through filters, or whatever. The camera application never needs to know about the filter application (the reverse is also true). This makes it very easy to reuse code and for users to design their own workflows. Platforms don't really like this, since they don't have total control over the user experience, but for us users, it's pretty darn nice.

(You can also register URL handlers, so that something like clicking a link to Google Maps in your email automatically opens up the Google Maps app to the same state. Again, pretty useful.)

in fb camera, if you see someone is tagged, and you tap their name, it switches to the main fb app and shows their profile there. The notion of doing one thing well seems to be preserved.

It's somewhat possible though not very widely used.

Basically, any iOS app can register a URL scheme and be opened with that scheme and anything after that by another app. This is used for example by Camera+: http://api.camerapl.us/app-api

With their API, another app can launch Camera+ to edit a photo and Camera+ sends the user back to the original app with the data of the edited photo.

Facebook uses it for single-sign-on of third-party app. (i.e. user taps "sign in with Facebook", the Facebook app is launched, the user taps "Accepts" and is redirected towards the original app)

One big limitation of this mechanism is that it's very much ad-hoc.

Another existing mechanism is the one where apps can register themselves as being able to handle a certain type of documents. You can then open a document from another app.

Reply on news.ycombinator.com