<br><br>On 3/22/07, Ian Stirling <<a href="mailto:ian.stirling@mauve.plus.com">ian.stirling@mauve.plus.com</a>> wrote:<br>> Andreas Kostyrka wrote:<br>> > * Jonathon Suggs <<a href="mailto:jsuggs@murmp.com">
jsuggs@murmp.com</a>> [070321 22:58]:<br>> >> Andreas Kostyrka wrote:<br><snip><br>> >> My challenge is just to think bigger. Think how this could be incorporated to work with *any* phone. Then you can have a much larger group of people to brainstorm, test, and bugfix.
<br>> >> We have enough protocols and standards to support. Creating yet another one isn't really going to help that much. Also, I don't know anyone else that is planning on getting a<br>> >> OpenMoko device, so its pretty pointless for me at this point. I know you've got to start somewhere, but starting out a battle fighting uphill isn't the best of ideas.
<br>> >><br><br>what about sacrificing a few bytes at the beginning/end of the compressed data to include "to decompress, forward to xxxx". If you've got an openmoko/other compression capable phone, this would be disregarded, but for the vanilla phone users out there, forwarding to that number/short code would send the encoded data to a decoding server, which would then call back to the sender with the decompressed message(s).
<br><br>it's not really that good a solution, kind of kludgy, and it would cost whoever you sent the message to several extra texts. On the other hand, it generates some interest, and shows a tangible benefit to purchasing an openmoko phone... for the heavy sms'er this could even start saving them some cash.
<br><br>anyways, I got to thinking of the compatibility problem, and this popped into my head... hopefully it'll help spur some more ideas<br>-- <br>Jeff<br>O|||||||O<br>