Chris, The logic to parse an Office document is going to be on the server for now. Yes someday a JS application could do this but for now all web- based applications that eat Office documents (Zoho, Google Documents and soon our own) do so with various libraries that run only on the server. So this speaks to using much of the same mechanism that you currently use for uploading "captured files". Here is a scenario off the top of my head:
An application registers a file type and and a URL to be invoked when the file type is clicked. This is subject to the restrictions you mention. The file is then captured as though it was uploaded offline and is available to the FileSubmitter class. You can auto-generate a URL for the resource using a GUID plus the actual name of the file and pass the URL to the application via the OnFileOpen callback as you describe (assuming the URL is running somewhere). If the application is online it can upload the file and parse it immediately and if it is offline it can promise that it will do so as soon as the internet connection is restored. On registration I do think you need a very explicit dialog to let the user know that "files of type xxx will be sent to application yyy. Do you trust yyy?". One final thought. As web applications gain acceptance many users will have Microsoft Office or Open Office installed and so it might make sense that an application can register a file type for an already-handled type and when a file of that type is clicked on, the user is then offered a choice of destinations via a popup menu. This is just expanding on asterisk 1, dash 1. This would be a very "game changing" feature for those off us implementing applications in the office productivity space. ....Sam On Oct 8, 1:30 pm, "Chris Prince" <[EMAIL PROTECTED]> wrote: > Hi Eric, > > File associations are idea we have discussed briefly. A couple thoughts: > > * Rather than prompting the user on unhandled file types, I think > applications would want to register for file associations. Two > reasons: > - Apps may want to register for already-handled types. > - Apps that don't register for a type likely won't be able to do > anything useful with it (if the user creates the file association). > > * System file associations would probably need a permission prompt, > similar to desktop shortcuts. > > * We would need to figure out how to expose the file data to the web app. > A handler like onFileOpen(blob) makes the most sense to me right now. > I've also heard talk of posting to a URL, but getting the protocol right > sounds tricky. > > On Wed, Oct 8, 2008 at 8:50 AM, Eric-Sebastien Lachance > > <[EMAIL PROTECTED]> wrote: > > > Nicolas, > > > Your solution for opening the webapp documents (like a doc residing on > > google docs) from the desktop is good, but it's the contrary to what I > > mention, e.g. opening a local doc from the webapp. This is especially > > important when an organization (such as us) have 300 employees > > managing hundreds of office documents on a shared drive, and a > > transitional period is required to switch to a new system. > > > I do see what you mean in your first paragraph about sending a > > parameter to the webapp. Though I haven't worked with the code (I'm a > > client/user, not a developer), I see the logic in it. > > > I've followed Ben's suggestion and opened an issue (http:// > > code.google.com/p/gears/issues/detail?id=745) for this, but here's how > > I see it working: > > User double-clicks on the file, and selects to open it with Google > > Gears. Gears sees the file and asks with what "WebApp" you want to > > open it with, where you can select the one you use (for example, I can > > select between Zoho Writer and Google Docs at this point). It's an > > extra setup step, yes, but this would be the ideal way of doing things > > I think. Perhaps a Gears interface to manage the file associations > > would be a good idea also, to do the process in a reverse order > > (create a new association, select the file type, select the WebApp. > > > Thanks for your time guys, I hope this becomes a reality soon! > > > Cheers, > > Eric. > > > On Oct 8, 10:40 am, "Nicolas Roard" <[EMAIL PROTECTED]> wrote: > >> On Wed, Oct 8, 2008 at 2:57 PM, Eric-Sebastien Lachance > > >> <[EMAIL PROTECTED]> wrote: > > >> > Ben... > > >> > I strongly hope that I'm not the first one to have thought of this, > >> > because if I am that should merit me a job at Google (got a > >> > "Brainstormer" position open?) :P > > >> > Nah, seriously though, if any online application is to become a > >> > replacement for a local one (if Docs wants to replace Word, GMail > >> > replace Outlook) then in a sense you have no choice but to mimic not > >> > only the software functionality, but the OS functionality. Having a > >> > file association to a software is a behavior that people are just used > >> > to. > > >> > In order to offer a service for the "masses", you have to think like > >> > the masses, not like geeks! > > >> I think this is a good idea; there are various ways that could be > >> implemented. > >> e.g. we could create a blob with the file, and have an additional method > >> to the > >> filepicker api that would returns that blob (so webapps upon starting could > >> call a getParameter() method or something like that). > > >> As Ben said, what you can do right now if you simply want "documents" on > >> your > >> desktop (vs opening existing file types) for your webapp, you should be > >> able > >> to create shortcuts using the desktop api (then it's just a matter for > >> your webapp > >> to create shortcuts with url containing the document id so that it can > >> present it to the user). > > >> -- > >> Nicolas Roard > >> Google UK London
