dear skype,

for linux [don't for god's sake do this for windows, windows users will NOT get it] please could you create a client/server architecture and release an "almost" unrestricted license on the header file, library and server-side.

when i say client-server architecture i mean a split at the USER INTERFACE end NOT anywhere else.

in other words, please be kind enough to let the KDE team write a front-end for your application, let the Gnome team write a front-end for your application, let some idiot write their own command-line front-end for your application, etc. etc.

the API should:

- provide a means to register and log on
- search for contacts
- make and receive a phone call
- send and receive instant messages
- provide some text for an "About" box / Credits.

etc. etc.

in other words, _you_ can focus on what you're good at [doing distributed applications] and _if_ you get the licensing right, you'll be freed of the burden of writing user-interfaces for open source applications.

i recommend that your license be unrestricted in who can write front-ends, BUT that you require people to use your logo and also that they MUST use _your_ "About" box text / credits.

something like that - take a look at the GiFT project which is a client/server architecture where the client does all the GUI stuff and the server bit does all the distributed file sharing.

same thing, only proprietary server, but open source clients. or whatever.

Yes yes YES. Please!!

Then I can write a plugin for gaim - god I have having multiple clients open

I second this thread. This would be very good. Would be nice to have a selection of front ends

Cueball

I third this. This would be cool, especially if there was a way that developers could implement their own sound interface to it, so we could have a version using OSS, a version with ALSA, a version with aRts, etc. The problem with Linux is that there are so many different distros with different desktop systems, etc, so it's a confusing mess. If Skype provided us with libs to implement our own Skype clients, then all this would be resolved by the community.

What we will do is release a Skype API that allows you to invoke Skype functions from other apps. This will most probably be in the form of DBUS messages/responses. So you won't be directly able to implement sound API calls and other such low-level stuff - this we will still have to do ourselves - but you will be able to perform all Skype functions from your own software (but Skype still has to be running in the background).

does this include possibility to tell the API not to ring via the
soundcard that is used for voice?

this would allow to ring over the soundcard that has speakers,
and have voice over the headset

they should add this feature anyway. it's already part of the windows version and it makes perfectly sense.

and a Bayonne plugin, so that people who run bayonne can have PSTN telephones answering and making Skype telephone calls.

and someone can write a skype answering service.

teehee.

ARGH! ohno, not dbus! arg arg arg *sad*. yet another application that will use the already-duplicated-functionality-of-FreeDCE-because-the-dbus-developers-didn't-do-their-research-to-find-out-if-there-was-anything-equivalent-to-what-they-wanted-to-achieve
(http://sf.net/projects/freedce).

oh well. dbus is better than a kick in the teeth.

l.

giFT frontends such as apollon "fire up" a giftd on demand.

they detect that it isn't running, and exec one for you.

given that the daemon runs on high port numbers (except it tries to bind to port 80 which you cannot do under linux except as root) it's perfectly acceptable for the daemon to be run up on-demand by the user front-end.

_plus_ it actually might be necessary: each user on a multi-user linux system is going to have to fire up their _own_ daemon so as not to interfere with other users.

which is why you should be using DCE/RPC (FreeDCE) dammit not some jumped up upstart redhat-sponsored "not invented here" project grumble grumble ignore this entire sentence.

anyway.

what you will need to do is make sure that you fire off a skyped that creates its own message bus SPECIFICALLY for use by that user. if the message bus is a unix domain socket you will NEED to create a directory
e.g. ~/.skype/dbus-directory and then chmod that directory's permissions to 0700. THEN you get the skyped to create a unix domain socket in that directory.

the reason is because the creation of unix domain sockets on some unixes you CANNOT chmod the permissions of the domain socket file, so you must create a directory instead.

if you want some example code to look at, see www.samba-tng.org.


l.

Hi,

do you guys have a date for when this API will be making an appearance?

Cheers,
Waider.

Sorry, no. But when it does, it will first be announced in these forums.

Will the API be free or commercial?

Or will that depend on the level of support required?

Yes - free for "as is" use, probably also some commercial options available.