A New Approach to Printing with Google Cloud Print | Hacker News Reader

A New Approach to Printing with Google Cloud Print

blog.chromium.org

64 pointsmqt25 comments

I love the decoupling the driver from the PC idea, but I can't help but wonder where this is all heading.

Isn't Google just re-inventing the mainframe, where they own the mainframe and the rest of us are customers, er dumb terminals? In other words, is this an open standard where any two web-enabled devices can communicate? Or is it a Google-managed service ("we return the status of the print job back to you") where we're yet again investing in the success of Google? Seems like the latter to me. Perhaps I misread it.

They're proposing standards for all the levels, so, in theory, other "cloud printer" providers could do what they do.

So, in theory, it's not lock-in to their cloud.

In practice, who else is going to do this?

I suppose if there were a common OSS solution that one could run per-company or per-workgroup, that'd be great.

open standard is not open just because there are no loyalties. a standard is open when it's managed by a consortium or task force. OpenGL is one, for example.

The cloud is not an awful lot different in principle to when we used to lease managed IBM mainframes.

I find it hilarious how quickly the IT industry forgets the past. The thick/thin client rotation has been going on since before Unix epoch.

It's all just a little bit of history repeating...

Hey, if I enable adwords on my printed documents, will Google pay for the ink? Do that and i'm sold :)

i really really really want dropbox to print to this. it would be nice to print from a phone or a browser, without having to open the actual file.

I sure wish they'd propose something similar for scanners.

+1 to this. I wish there were a unified standard for networking scanners at all, actually. The majority of business scanners have arcane features to Email, FTP, or SMB-share the documents they scan. SMB is the usually only thing that invites practical use on a small business network, and the scanner's implementation of the protocol is almost always poor. I've encountered $5k copiers that could only copy to SMB shares on Windows XP, mysteriously failing for Server 2003 or Server 2008. I don't even want to think about trying it with Samba.

Networking a copier is no afternoon job, either. I've seen businesses where setting up their copier on Ethernet was such a bother that they just hook up the fax line instead and fax everything to their own eFax number whenever they need a PDF scan of a document.

My dream is that I could plug in an IP address/hostname to any scanner and I press Scan. The scanner contacts a daemon running on the host on a well-known port and protocol (if it's the first time, the host presents a dialog or something to confirm pairing) and then the file goes shoop over the network into a folder of my choosing.

Why does this not exist! In a networked world, scanners need to be more like faxes, except there is no fax equivalent on the TCP/IP level.

I want something less complicated than that. I want to push the Scan button, open my web browser, select the scanner from it's list of Bonjour (aka DNS-SD) discovered web services and then browse, save and delete scans from it's web interface.

Exactly - combine the 2 and you might finally kill off the dreaded fax machine (which despite being more arcane than the floppy disk, stubbornly refuses to die)

My parents were trying to get a fax machine working over a VOIP line the other day - a 19.2K modem on a 20MBit DSL connection. Makes you cry a little when you think about it.

Heads up: Fax won't work over plain VOIP because of the audio compression; it's unlikely they have a gateway available on their network that will do T.38 FOIP, they'd need a real POTS line to send a fax (or use one of the many internet fax services).

Where was this ten years ago when I needed it? I worked for a electronic medical records ISV, and we had requirements like: Print referral letters on regular paper, chart notes on paper with a special blue line on the edge, and prescriptions on a special printer. Our thick Java Swing client was at the mercy of an admin to configure each workstation correctly. Even then, we could not easily do things like print to an alternate printer when the primary one was not working.

I had envisioned some sort of document printing service which could receive a request from our back-end services to render and print, say, a RTF document using a specified set of print rules (paper requirements, micro-geographic preferences, etc.).

Seems a lot like IPP. http://en.wikipedia.org/wiki/Internet_Printing_Protocol

I can already print from anywhere in the world to our work printers which operate on a CUPS server with authentication and SSL. I don't need a special driver, a generic print Postscript or PDF one works.

My former employer spun off a company based on exactly this problem: http://www.thinprint.com

They did very well back then and probably still do. If I had any stock, however, I'd probably sell around the time Cloud Print looked like it would get traction...

Hmm, I could see this working in an Airport Express USB print kind of way; but too bad, Airport Express still requires the printing origin computer to have the printer drivers. If Apple (or anyone else for that matter) Express can support cloud print, that would be so much nicer.

dd-wrt maybe?

Thanks - a good find.

P.S: Love the profile blurb about being lost :-)

thanks :)

This seems like a step backwards to me. Why are they even wasting cycles on this when we're obviously heading to a paperless society? Maybe they should make cloud fax services too.

Because we've been "heading to" a paperless society for 35 years now, and we've still not reached it.

Sometimes a piece of paper is just _better_ than a laptop/tablet/PDA/phone.

Google adds more data to their store. Will Google be retaining the documents to be printed in any way?

If you readed the linked article, it says it could work offline, the whole protocols are open source.

I'm not sure, but according to the patch, only client and proxy are open source. Cloud print service seems to be closed.

http://codereview.chromium.org/1566047/show

How would this practically work? Do we need new printers for this?

Read http://code.google.com/apis/cloudprint/docs/overview.html

And, finally, the number one question people ask is, "How do the printers communicate with Google Cloud Print?" The answer is, "It depends on whether the printer is a cloud-aware printer or a legacy printer."

They're proposing a proxy for legacy printers in Chromium (that makes Windows/Mac OS X/Linux printers available to Cloud Print). They're also proposing that new printers add native Cloud Print functionality.

For Chromium OS, it seems like it will only be able to use new printers or legacy printers with specific proxy devices.

Reply on news.ycombinator.com