Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On Thu, 2006-11-30 at 20:20 +0100, Koen Kooi wrote: any spare(ish) cycles you have I'd vote for using them to put up a basic community wiki - makes it easier for project ideas to get off the ground when there's a common source for information, not least with relation to the ability to upload design diagrams + status tracking. Yup - it could become an incoherent jumble, but as a stop-gap until the repositories/tracking are in place, it would be ideal. You could use the http://www.linuxtogo.org/gowiki/ wiki for that till the official wiki goes live in 2007. I see this as an issue of centralisation vs. fragmentation. I'd prefer to have one source to go to for all things Moko. :-) Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On Wed, 29 Nov 2006, Robert Michel wrote: *IDEA* Wait, because these systems support USB mass storage device - couldn't we use a normal browser and on download to a FIFO file and an upload to a FIFO to FIFOs on our server? So no local installation, nor Java support (I would have doubts that Java will be allowed to access the USB mass storage device, especialy not a USB network device...) So with this trick we could run an SSH tunnel via the FIFOs and would have Internet connection on our NEO at all these locations :)) This is a brilliant idea. Not only is USB mass storage supported on every modern computer, but Internet cafes, shops, and libraries are used to seeing people plug them in and don't consider them a threat (although perhaps they should). The phone is a USB host. So is the computer, so don't you need the USB On-The-Go protocol to determine which is going to host and which is to be the device? Or is there some other way this work? I might dig around the Linux implementation a bit to learn more. I find this idea very interesting. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On 11/29/06, Robert Michel [EMAIL PROTECTED] wrote: *IDEA* Wait, because these systems support USB mass storage device - couldn't we use a normal browser and on download to a FIFO file and an upload to a FIFO to FIFOs on our server? So no local installation, nor Java support (I would have doubts that Java will be allowed to access the USB mass storage device, especialy not a USB network device...) So with this trick we could run an SSH tunnel via the FIFOs and would have Internet connection on our NEO at all these locations :)) This would avoid the need for and USB eterneth adapter and the best: - Our device would be charged during visiting the internet cafe - no softwareinstallation on the workstation neccesary - no network configuration - AND it would work with other people PC/Laptop as well - beeing on the campus / caffe / airport lounge where other use Wlan - just ask them to plug in your USB cable and use a ssh tunnel over bidirectional webbrower to USB mass storage device routing I thing this hack would need some keep alive packed from time to time ;) A possible problem with the FIFO-file for networking idea is that it's a bit trickier to determine exactly when the PC side will send data to the Neo, instead of caching the file locally. Or maybe I don't understand the implementation of your idea? How would the browser 'know' how to automatically use a FIFO-file? If I'm in a web-cafe, I hook my Neo into the USB, point the PC browser to my trusted server.. there's a link missing: Neo/USB/?FIFO?/browser/server Now.. you could hack the PC-side to write-immediately to the USB device, but files are not FIFO in the ring-buffer sense.. that could be hacked on the Neo end.. hmm.. I guess the results stream could be just that - the equivalent of downloading a file of unknown size. To upload (Neo-Server) requests.. that may be more tricky.. because you want to upload without continuously hitting the 'file upload' dialogue -- a fetch will (IIRC) see a file of X bytes, and upload just those X bytes. Still not sure about the Neo-PC-Server communication path, although the Server-PC-Neo path is easier but with some hacking. Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the PC browser to the HTML file on the Neo's memory, you could in effect set up a meta-refresh every second or so, or use AJAX to read files (requests) from the Neo's memory, and pass them on to the external Server as subsequent requests. GWT has a nice feature whereby it regards return requests as asyncronous events. All it would require is javascript support. Neat! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On 11/29/06, Richard Franks [EMAIL PROTECTED] wrote: Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the PC browser to the HTML file on the Neo's memory, you could in effect set up a meta-refresh every second or so, or use AJAX to read files (requests) from the Neo's memory, and pass them on to the external Server as subsequent requests. GWT has a nice feature whereby it regards return requests as asyncronous events. All it would require is javascript support. Hey! This is the first project idea which we (the community) could start today and complete even before the first Neo1973 ships, without access to the SDK or any other data. Booya. There would be three components: 1) A small utility (cpp? Preferences?) which: * Runs on the Neo and opens up a localhost port - the Neo would connect to this. * Sets up a ring-buffer (implemented by files: request1.html request10.html) * Forwards results it receives back from the server (via the browser) to the localhost client 2) The AJAX part which handles the PC end of the bridge 3) The server utility which speaks to the PC and understands the Neo1973 requests it receives... or just passes it on in the case of an SSH tunnel. There is actually a disconnect on the AJAX-Neo side - not sure of the best way to get the return data from the browser back onto the Neo's filesystem for dissemination, without invoking the file-download dialog. Streaming is one way, but would require kernel hacking to implement a file as a ring-buffer? If it's not a ring-buffer then you run out of storage space. Oh wait, the file the PC browser writes to on the USB stick, can be implemented as a symlink by the Neo.. to a device instantiated by the app (1). Ok, good - did I miss anything? Who wants to help develop this? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Franks schreef: snip Hey! This is the first project idea which we (the community) could start today and complete even before the first Neo1973 ships, without access to the SDK or any other data. Booya. That isn't true. You can start coding a a pure gtk+ app right now, and it will run on the neo quite well. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFbfpkMkyGM64RGpERAvILAJwIVslp1z6J9ZArVt+wqZzg6jSB4ACfaqKb 1GLtzIFK3r+5D+ZMHezcqu4= =I7j9 -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
