Warning - removing plugin APIs (was S60 5th Edition SDK API Plug-in release delayed)

[ltomuta]

To whom it may concern:

We are planning a bit of cleanup in plug-in's content as we believe some of the APIs included there are no longer relevant or that the use cases they enable have never really been of interest to developers.

To help us have a clear understanding of which APIs are indeed a must have for the plug-in and to ensure that we don't remove APIs critical to your application development I invite you all to comment here (or by email) with details about which plug-in API (or APIs) you use and which is the use case that makes the API critical to your project. Having also the name of the application you have developed/released using the API would serve as a success story and a confirmation (we hope) that the plug-in APIs serve they role in supporting inovation on the S60 platform.

Thank you for your help!

[ruchirvasavada]

I really appreciate the way guys are concerned about the developers.

We extensively use PhoneClientExtension APIs in our application. As far as I know, this is the only API which allows call related functionalities without call id. This API is missing even from FP2 SDK plug-in. :(

We also use MMF decoder (mmfdecoder.h & related libs). In FP1 & FP2 SDKs, mmf plugins are available but this particular header file is missing. I even couldn't find any replacement to that.

As of now our list ends here.

Thanks,
Ruchir

[Sorcery-ltd]

Hi,

I have an application that uses CMMFCodec (specifically the MP3 decoder at the moment in my case), same as Ruchir. It isn't public yet (and may not be for some time due to UI design issues). That API isn't actually in any of the plug-in packs, although it was in the old extension plug-in for 3rd MR. Please can we have it back for the new plug-in pack?

The same application also uses the MMFDevSound API and the Profiles Engine (although I think the updated version of that is in the main SDK now and I don't use the extended API from the plug-in pack).

Although no-one has yet answered here about it, I've answered loads of questions from people on the DiBo about using the Media Recorder API, so I assume that is still needed.

Also, I am planning an application that will probably use the New File Service Client API, at least in the first version.

Cheers,
Mark

[ltomuta]

Thanks Mark.

It is important that those using the APIs do give feedback about them so that we know how many they are and how many use cases. There is a reason for these APIs not to be in the SDK so unless they are really needed and used we shall take them back from the plug-in.

I have seen also a lot of discussions about the "Silent Installer" API but unless I see it mentioned here explicitly I'm going to assume that it was only used for test applications and that until the API is ready to be added to the SDK we can safely keep it internal.

[jas76]

Hi ltomuta,

Thanks for taking feedback from developers. We really apprecitate this. We are using

1) Phone CLient Extension API
2) Profile Engine Extension API (Using in 3rd Ed MR. However same features are available in FP1 as part of public SDK, so if public SDK carry forward Mproeng* classes in public SDK then we may not be concerned about this).
3) Call Audio Control API
4) CR Keys to control Volume

Appication is not released yet. We are expecting to file for symbian signed in Dec and final releae at end of Jan 2009.

Thank you very much again for collecting the feedback.

Best Regards
Jas

[gailu]

Hi ltomuta,

I know what we are requesting may not be feasible for you guys but we would like APS or any alternative to Audio uplink and downlink record. Our application is based on these feature and project can't go further if there is no means to do that in 5th ed. Unfortunately alternative of APS (Voip Audio Service) does not provide this feature. This is our request if not APS then classic MdaAudioPlayerUtility/CMdaAudioRecorderUtility or any other alternative will be highly appreciated.

Thanks For your considerations.

[ltomuta]

Hi gailu,

this thread focuses on the current content and parts of it being removed if not needed. As soon as I close this thread I will open one for a wish list although I cannot promise much in that direction, adding something to the plug-in is much more complicated than removing :)

[skumar_rao]

Hi
My list some what bigger.

1) Phone CLient Extension API
2) SW Installer Launcher API
3) Phone Client USSD API
4) SMS Utilities API
5) Browser Launcher API
6) Profile Engine Extension API.
7) Call Audio Control API ..

[rpunskyy]

our list is mor or less the same as skumar_rao's + Multimedia plugins and remote bluetooth.

[jonnekodu]

Hi Itomuta,

This is the SDK extensions that we use in our application:

1. Audio Proxy Server API (3.0 only)
2. Phone Client Extension API (3.0-3.1)
3. WLAN Management API (3.X)
4. WLAN Settings UI API (3.X)
5. VoIP Audio Service API (3.1-3.2)
6. Call Audio Control API (3.1-3.2)
7. Audio Routing API (3.X)
8. Logs UI Command Line API (3.X)
9. Remote Control Extension API (3.X)

Kind Regards,
Jonne

[eartle]

Hello,

Michael Coffey of Mobbler here.

We are heavily reliant on the Music Player Remote Control API. We also use the Browser Launcher API, but could get by without it.

Cheers!

Michael

[rob_savageminds]

Hi,

Thanks for asking! You might want to consider renaming this thread to make sure it gets the attention it deserves. Something like "Warning - removing plugin APIs" might grab people :)

We are reliant on:

Audio Proxy Server (VOIP Audio Service API doesn't do what we need)
WLAN management API
MMFDevSound
Silent Installer API
Phone Client Extension API (why not in FP2?)

Our software platform is installed on over 10k handsets but we're struggling to support current handsets due to missing APIs in FP2 onwards.

I have a question for you - what is the argument for taking these APIs away? They are very clearly labelled as not supported, so is there a cost issue to putting them out there? Is it just for the clutter / the fact that you're not sure they are being used? We have business opportunities that came about entirely because of the availability of these APIs. If they weren't there we would never have pursued them.

Please give us more APIs not fewer!

Cheers

Rob

[skumar_rao]

thanks for suggesting the name change now it look more important.

About your question, i want to ask taking our development case as example we have a similar question that we wanted particular APIs that where part of previous Plug in SDKs but not with new FP2 SDKs. So we contacted Forum Nokia For Partnering API and we got the APIs ...

[samooha_2020]

It's very nice from guys trying to remove developers pains.
In our case we are using the MediaRecordeApi . Our application main feature is built on this API.
The requirement is to record audio/video with specific codec and get access to recorded data without waiting tell the end of recording session and get access to recorded data frame by frame for audio and video.

Thanks,
Sameh

[luzi82]

- Media File API
- MMF decoder