Another issue with MIDP is that you can't access any of the internal databases (address book, date book, to do, memos...). It's a security thing (you don't want apps you download to be able to read/write your contacts). But it's also annoying for anyone wanting to write apps that do things with the information you already have on a palm.
The Java Spotless system (the forerunner to MIDP/CDLC) did allow you to do this and from memory had a richer UI... but it's dead now. See MIDP4Palm FAQ. I hope the PDAP picks up some of the Spotless systems' abilities.
...and as I understand it the SAMBA folk have done an amazing job because they've been working without documentation --- having to reverse engineer a proprietary (and changing) spec.
It's important work because Microsoft's network file system thing became so wide-spread... so we needed support for it.
What worries me about going along with the ".NET framework" is that
(a) you're helping making that framework widespread, and then
(b) I expect MS to change the API in some way to make life hard, leading to
(c) having to do what the SAMBA folk do, and try to reimplement something that was "open".
I dunno. I just get a baaaaaad feeling about this.
Slashdot Mirror
Another issue with MIDP is that you can't access any of the internal databases (address book, date book, to do, memos...). It's a security thing (you don't want apps you download to be able to read/write your contacts). But it's also annoying for anyone wanting to write apps that do things with the information you already have on a palm.
The Java Spotless system (the forerunner to MIDP/CDLC) did allow you to do this and from memory had a richer UI... but it's dead now. See MIDP4Palm FAQ. I hope the PDAP picks up some of the Spotless systems' abilities.
> But with no support for multimedia now (sound)
> don't expect these games to be anything amazing.
They're not tooooooo bad. There are a few to try at midlet.org
...and as I understand it the SAMBA folk have done an amazing job because they've been working without documentation --- having to reverse engineer a proprietary (and changing) spec.
It's important work because Microsoft's network file system thing became so wide-spread... so we needed support for it.
What worries me about going along with the ".NET framework" is that
(a) you're helping making that framework widespread, and then
(b) I expect MS to change the API in some way to make life hard, leading to
(c) having to do what the SAMBA folk do, and try to reimplement something that was "open".
I dunno. I just get a baaaaaad feeling about this.
Strange. A couple of weeks ago I wrote down some thoughts on how to build a MUD to WAP gateway.
It's in PDF and it's full of bad English, but I'll fix both of those issues "real soon".
http://www.dallaway.com/mud/index.html