<div><div>It's nice to have rational conversation and argument about this, rather than the great amounts of handwringing which sometimes constitute the bulk of these discussions... <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The "burden" of a skype client is not primarily in the UI, most people<br>would be happy to just have a way to run Skype on their phone, the<br>same as they run it on their desktop. Its easy to write a very simple
<br>plugin that extracts the contact list info from Skype, so that it<br>could be presented in the OpenMoko PIM, and the PIM could call Skype<br>to start a call or chat session without even using the API, its a<br>command line option. What more do you want to do?
</blockquote><div><br>You're right. Users will be perfectly happy to just run skype on their phones. I guess I had overestimated the Skype gui's requirements. From a developer's point of view, if I'm writing a general dialer and contact app, I would prefer the user just be able to add skype contacts from within my app, rather than having to pull up the actual skype interface, or install and use full blown program. I don't want do de-Skype things, just make interoperability as easy as adding a sip contact or a PSTN number.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The Skype Java API that I have been working on is an Open Source project<br><a href="https://developer.skype.com/wiki/Java_API">
https://developer.skype.com/wiki/Java_API</a> created outside Skype and<br>hosted on SourceForge. Skype is helpful but doesn't contribute code to<br>this effort.</blockquote><div><br>This is an excellent suggestion, assuming java is available on the NEO (no reason it shouldn't be). If the developers of that project are willing to assume the burden of the Skype license, other open source developers should be able to use that project without further qualms regarding Skype's API licensing requirements.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are two kinds of Skype API developments, one is for embedded<br>devices, which license the Skype core and are a source of revenue,
<br>hence most of the contract tries to protect this revenue stream. The<br>other is the Skype desktop plugin API, which is used to produce tools<br>that enhance or leverage Skype in some way. If you want to publish a<br>
Skype plugin on the Skype developers web site or get it promoted in<br>the Extra's gallery then the license is needed, but there is nothing<br>to stop anyone writing code that uses the API without telling Skype<br>about it.
</blockquote><div><br> Yes... the NEO will probably need more than a plugin, considering the fact that without a great deal of work, the default skype UI is probably not going to be particularly suited to this device, and certainly won't be integrated with whatever input systems are eventually developed (pie menus, as one possible example). As an end-user, I would prefer a skype experience that is integrated into my phone as much as possible, so that a skype call looks similar to a sip call looks similar to a PSTN call. This may not be the way everyone feels, but it's the functionality I'd be shooting for.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree that smartphones such as the Neo are in a grey area between<br>general purpose desktop platforms and special purpose embedded
<br>devices. However an embedded device including Skype, and that has a<br>Skype logo on the box at the point of sale, clearly needs to have some<br>license agreement and Skype performs a lot of in-house device testing<br>
to make sure that these implementations work properly. The general<br>purpose versions of Skype are downloaded from the web and installed by<br>the end user, and I think that is a clear distinction. If Skype was<br>bundled and advertised as part of the Neo/OpenMoko product then it
<br>would need a license. This seems like normal commercial terms to me.</blockquote><div><br>I agree with what you're saying. However, if I (as a developer) provide a download that allows an integrated Skype experience on the NEO platform, I would not want to be the one arguing in court that the package did not constitute a "Hardware Device." You've given clear cut examples of how that is meant to be applied, I'm thinking about the more murky things that could happen, and which would discourage development.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You shouldn't ever cache the Skype password outside Skype, it uses PKI<br>to obtain a session key, and as long as that key is valid you don't
<br>have to give your password. I leave Skype running for weeks on my<br>laptop (on/off line and several networks), and only have to sign-in<br>once. When I restart Skype it remembers my password internally as long<br>as I'm not switching between Skype accounts. This is important for
<br>maintaining security for Skype users.</blockquote><div> <br>I agree... there's very little reason for us to cache the skype password. But if we're talking about an integrated function-library type application rather than running the full-blown skype desktop ap in the background, these needs may be different. I wouldn't want to have to put in my skype password everytime I power cycled my device or reset it.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm not sure that our only goal is "total integration". If I want to
<br>run Skype on my phone, I may want to use the standard Skype UI. A<br>plugin could do addressbook integration as it does on the desktop.</blockquote><div><br>We're talking about a limited resource device. Running the Skype desktop application all the time in the background is not the most optimal solution if a more streamlined one could be made available. In addition, a device like the NEO is going to need fairly specific network activity profiles... For instance, we probably want the user to be able to send and receive text messages via GPRS, but we don't want to generate much traffic over that type of link otherwise, and certainly can't accept voice calls. We don't want the device to act as a proxy (probably ever, due to battery life concerns). When it's connected via a broadband connection, we still want low-resource usage where possible for power saving reasons.
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you use the open source Java API you insulate from this problem.<br>
The Java API developers are tracking additions to the underlying Skype<br>API. In practice the API has been very stable with additional<br>functionality being added in each release. You have to make sure that<br>the copy of Skype you are using implements the features you need, so
<br>my code has a simple test for minimum SkypeVersion required. The Java<br>API is also multi-platform so the same jar file includes Skype API<br>platform specific connector code for Windows, OSX and Linux.</blockquote><div>
<br></div><div>Yes, this is probably an acceptable solution to this problem. It is still probably not optimal, however, because it introduces an overhead. It also means that the developers of the integration software are not allowed to use the word Skype or any of the logos either in their program or in promoting it.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The underlying Skype API is very simple</blockquote><div><br>Yes, this is great. But if I can't use it because I won't agree to the T&C which expose me to great potential legal liability, what good does it do me?
</div></div><br>I think that (as with most things related to the NEO) there are a number of different ideas and expectations regarding Skype. One option is to run the desktop app seperately, and integrate where possible using the API appropriate for that. This is probably the quickest solution, assuming we can get arm binaries. Another is to use the API (or the java api, to insulate from legal liability) to call the skype application running in the background. This is suboptimal because it has the added overhead of running the GUI without presenting it to the user, and still requires certain user interactions with the stock GUI (put in the password, etc). This will certainly detract from the integrated feeling. A third (and at this point fairly unlikely) option is that of a compiled binary library which could provide an interface for complete integration, making skype a protocol which could be used similar to the others. One advantage of this is a customizable network traffic profile probably not available with the others.
<br><br>My guess is that at some point, we may get a ported GUI, which may or may not be possible to integrate well with the rest of the device. We'll see...<br><br>-Paul<br>