Is the Orbiter software able to run on a PALM like PDA?

[archived]

Can the Orbiter software be run on a PALM OS PDA, in case it has BlueTooth or WiFi built in?

[archived]

there is no palm version.  We run on Windows, Windows CE (PDA's and mobiles), Symbian and Linux.

[archived]

Are the protocols that the Windows devices used to control pluto published some where so I could develop a bluetooth interface for palm and submit it back to the project?

[archived]

did you check our svn? http://svn.plutohome.com/pluto

[archived]

our orbiter software runs in two ways: 1) you run the actual orbiter C++ program on the device.  This is the way it works with Windows CE and PDAs.  Assuming that there is an ANSI C++ compiler for Palm, this would work for Palm as well.  We specifically wrote orbiter in a very object oriented manner so that the main class, src/Orbiter/Orbiter.cpp, which has all the logic, has nothing to do with the user interface.  it just calls virtual functions that are derived class must implement. primarily RenderText and RenderGraphic.  so if you did this, you would create a new class called OrbiterPalm that implemented the text and graphics rendering for Palm.  that's it--the logic and guts would still be the same ANSI C++ that runs on all the platforms

2) the second option is that the orbiter is basically a dumb terminal.  This is how Symbian phones work because the phone just doesn't have enough horsepower to handle the logic.  So in this case we have a derived version of orbiter class that runs on the media director--not the phone--and when you call the render method's it sends a prerendered graphic to the phone, and the phone just sends back keystrokes.  So in this case the phone has no idea what it is displaying, and absolutely no logic.  It is strictly a terminal that displays a prerendered graphic and sends back keystrokes.  I don't know how powerful the Palm platform is, but if the CPU is really low power you could use this approach.  Also, if Palm does not have an ANSI C++ compiler, this approach is probably better even if it had a powerful enough processor because this way you do not need to duplicate all the logic of orbiter in another language.  The C++ orbiter class is quite big, so if you have no C++, you don't want to rewrite the whole thing in another language.  So using this technique allows you to only write a function that draws a picture and sends back keystrokes, and the same C++ orbiter would run on the media director.

another possibility, if you wanted to do your own graphical user interface from scratch, is not even to use orbiter.  Remember all Pluto's devices do nothing but send messages to other devices.  So to start playing a movie, for example, all you do is send a message to the media plug-in.  You could do this using simply a telnet session.  All the communications are over a socket.  So you could actually write a completely new graphical user interface for Palm from scratch, and as long as it sends the same messages over a socket, it will still control everything.

which of these approaches sounds best to you?

[archived]

which of these approaches sounds best to you?

The Treo 650 has 312MHz RISC-type StrongArm/Xscale processor, 64MB RAM and 320x320 display.  There are several full C++ development environments for it, including CodeWariror (old and costly, but good) and Eclipse (free).  There's even a complete C/IDE that runs on the Treo itself.  The programming model is strikingly similar to the old Mac OS (pre-Unix) which also was developed in CodeWarrior, with the main drawback being that multitasking is cooperative, rather than preemptive and so while batterly life is greatly enhanced, running background apps (which is kind'a important on a device that doubles as a phone) is always a challenge.  Also, PalmOS is like MacOS in that it was originally born on the CISC-type Motorola 68000 architecture and was later ported to the RISC-type StrongArm (now-called Xscale) architecture using technology that preserves backwards compatibility by emulating the 68000 architecture.  Apps that want increased speed by running natively on the RISC chip do so using an awkward API and, of course, you have to run natively to do any kind of audio/video compression/decompression.  IBM also offers a free Java VM for the Treo and Opera has implemented a thin-client web browser using it, though the built-in Blazer web-browser on Treo is really excellent.  The Treo 650 includes 1xRTT (for CDMA networks) or GPRS (for GSM networks) both of which are like using a dial-up 56K modem (give or take).  The newer 7xx models have a smaller display, twice as much memory, shorter battery life and EVDO (for CDMA networks) which is like almost 2Mbps or EDGE (for GSM networks) which is under 200Kbps?

As far as getting Pluto running on Treo, I have my own custom system developed over many years that does most of what Pluto does (Myth, Asterisk, X10, etc..) and I control it from Treo using the Blazer web browser accessing a custom Apache cgi-app on my main server.  This allows for rapid changes to the visual elements/buttons by tweaking HTML --better than hand-coded C/C++/Java app.  This will also support iPhone or other devices in the future.  You could probably make a simple Treo 650 (32x320) web-app that is itself nothing but a client to your existing Symbian "terminal server" app, as gross as that might be.  At least you will have empowered Treo users while you come up with something cleaner.

I myself am toying with the idea of switching to Pluto, in which case I could help,  but I am on the fence, plus I don't know about how to integrate my customizations (OneWire, Growl, RS232-based sensors, etc..) in such a way that they don't get wiped out by the automatic update process.  Also, I would want SELinux and jobs that launch off of read-only media running all the time and checksumming/MD5ing every file on the disk to ensure nobody has tapped the system --so updates can only happen after I've updated the signatures on the read-only media.  Not sure how much info is being phoned-home to Pluto in update process either, but I am just getting into your docs/website.

So conclusion is this could go eitherway, simple web-app hack to empower Treo today and iPhone tomorrow or full blown C++ recompile with custom classes that call upon the PalmOS graphics and Bluetooth/comm libraries.

[archived]

we have added support for treo 700w.
you can try your 650. i think it should work.
basically it installs like a regular mobile phone, you make a peer with router download an app then install it.

pls let us know if it works with 650 too.