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...
The "burden" of a skype client is not primarily in the UI, most people
would be happy to just have a way to run Skype on their phone, the same as they run it on their desktop. Its easy to write a very simple plugin that extracts the contact list info from Skype, so that it could be presented in the OpenMoko PIM, and the PIM could call Skype to start a call or chat session without even using the API, its a command line option. What more do you want to do?
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. The Skype Java API that I have been working on is an Open Source project
https://developer.skype.com/wiki/Java_API created outside Skype and hosted on SourceForge. Skype is helpful but doesn't contribute code to this effort.
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. There are two kinds of Skype API developments, one is for embedded
devices, which license the Skype core and are a source of revenue, hence most of the contract tries to protect this revenue stream. The other is the Skype desktop plugin API, which is used to produce tools that enhance or leverage Skype in some way. If you want to publish a Skype plugin on the Skype developers web site or get it promoted in the Extra's gallery then the license is needed, but there is nothing to stop anyone writing code that uses the API without telling Skype about it.
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. I agree that smartphones such as the Neo are in a grey area between
general purpose desktop platforms and special purpose embedded devices. However an embedded device including Skype, and that has a Skype logo on the box at the point of sale, clearly needs to have some license agreement and Skype performs a lot of in-house device testing to make sure that these implementations work properly. The general purpose versions of Skype are downloaded from the web and installed by the end user, and I think that is a clear distinction. If Skype was bundled and advertised as part of the Neo/OpenMoko product then it would need a license. This seems like normal commercial terms to me.
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.
You shouldn't ever cache the Skype password outside Skype, it uses PKI to obtain a session key, and as long as that key is valid you don't have to give your password. I leave Skype running for weeks on my laptop (on/off line and several networks), and only have to sign-in once. When I restart Skype it remembers my password internally as long as I'm not switching between Skype accounts. This is important for maintaining security for Skype users.
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.
I'm not sure that our only goal is "total integration". If I want to run Skype on my phone, I may want to use the standard Skype UI. A plugin could do addressbook integration as it does on the desktop.
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.
If you use the open source Java API you insulate from this problem. The Java API developers are tracking additions to the underlying Skype API. In practice the API has been very stable with additional functionality being added in each release. You have to make sure that the copy of Skype you are using implements the features you need, so my code has a simple test for minimum SkypeVersion required. The Java API is also multi-platform so the same jar file includes Skype API platform specific connector code for Windows, OSX and Linux.
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. The underlying Skype API is very simple 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? 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. 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... -Paul
_______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community