A fellow student sent some e-mail attachment of technical report updates to a professor a few weeks ago, but he's still waiting for the update to be posted. I suggest that it is too much work for the busy professor to fish for the attachment from inbox, so he should send them again. I also wonder, wouldn't it be wonderful to be able to search our department's e-mail like Gmail does it?
It looks like Google Search Appliances shouldn't just be for searching an enterprise's Intranet web. What about e-mails and calendar items? Google now offers an array of applications—Gmail, Calendar, Chat, and Docs & Spreadsheets—which are ripe candidates for business solutions. They currently offer these services on a domain level as Google Apps for Domains. What about Google Apps Appliances? It looks like this is not a new idea; many people have speculated about it. Obviously, Apps Appliances are expected to provide search functionality like the Search Appliance.
There are some merits for Apps Appliances over Google Apps for Domains.
Privacy Companies enjoy greater privacy of data, as their e-mails, calendars, chat logs, and documents never leave the site. This is the same argument for Google Search Appliances.
Migration and Integration An admin should be able to integrate Google Apps with existing backend: NFS, SMB for storage of documents; Exchange, Notes for e-mail and calendar; IMAP gateway for e-mail. However, I can already see that Exchange and Notes integration will be hairy.
Google Apps for Domains currently can use IMAP gateway. Other forms of integration are not possible due to corporate Intranet security.
I think backend integration difficulty depends on how much integration is desired. It is difficult to interact with Exchange and Notes in real-time because these protocols must be reverse engineered. Efficiency is another consideration; these backends might not be designed to process massive amount of queries like the Google File System is designed to handle, and search performance (which is a hallmark of all Google Apps) will be severely degraded if that is the case.
It is easier to import and export data especially if everyone speak the same language (iCal for calendar, Unix SVR4 mbox for e-mail, and HTTP for document transfers). It is important that import and export should not lose fidelity of data, and the whole process should be automated.
Google Calendar allows import and export of calendars in iCal format, but I think each user has to do it one by one. This is clearly not feasible for a whole domain of users.
New Product—Filesystem Appliance Each Apps or Search Appliance will happily serve its own filesystem, but storage space can run out. When this happens, companies should be able to purchase storage solutions from Google and enjoy scalability and redundancy that Google File System provides. This is another business opportunity.
At this point, however, I want to stress that it is a bad idea if Apps or Search locks in to Filesystem Appliance by lack of network filesystem support such as NFS or SMB. This is because: (1) lock-in is evil by virtue; (2) companies who invested heavily on their storage solution won't be happy; and (3) a domain specific Filesystem Appliance cannot compete with general purpose network storage systems like Network Appliance products.
For now, without the Apps Appliances, I think the best way for graduate students to help busy professors manage e-mail attachments is by sending them again. It is as if graduate students aren't busy... Right?
No comments:
Post a Comment