The Symbian OS (779886), страница 81
Текст из файла (страница 81)
Where you have code like that which is so thinbetween two parties, between the top-side API users and the bottom-side APIusers, especially when they’re very broad, well it’s almost just worth gettingout of the way and letting the users sort it out between them. Actually an APIproduced by the creator of a telephony engine might well deliver the bestresult.It is possible, of course, to define, create and successfully manage‘thin’ frameworks. There are successful examples in Symbian OS, as wellas industry examples.Andy Cloke:A good example is Direct X, although it’s in a slightly different area. You havethe games developers on one side and the graphics drivers creators on theother side. It’s a tricky path to walk, creating that kind of thing.
You have tohave everybody bought into the fact that you need it, and then create a forumwith a number of graphics card creators and a number of games developers,and you need to mediate between them, which can be quite hard. Similarly,this is a hard thing to do in the telephony area.What makes it difficult in the case of ETel is the very specific dynamicbetween Symbian, as platform company, and its licensees, as phonemanufacturers.
Because licensees already have their own solutions inthis area – it is, after all, their very particular expertise – they do notnecessarily see this as a place in which the operating system either canor should try to add value. From the Symbian perspective, however,giving up its telephony offering would reduce the value of the platformfor potential new licensees lacking existing investments in telephony.Symbian stands in the centre of these conflicting positions.386JUST ADD PHONEAndy Cloke:Some licensees do not see this as something they require. They would like totalk straight to the silicon, direct to the baseband.
They don’t want anythingin the way. So they just want to know what is the minimal TSY that they needto create in order to support Symbian OS on top of it, and the rest of it theybypass. They just talk straight to the baseband.But that’s not the position of all licensees. For example, it is a matter ofpublic record that Nokia does not license its own telephony application(its crown jewels, or part of them) to competitors.
It is important thereforefor the viability of the S60 platform that its licensees should be able tointegrate their own (or a third-party) telephony application. For theselicensees, an application interface is critical and it is also critical that itis supplied as part of the operating system, so that it can be standardizedand controlled, since without a Symbian OS API between the applicationabove and the TSY below, there would be no standard for the interfacebetween the two, or at any rate no controlled standard.This implies a clash of interests between Symbian, those customers whoare in the business of making complete telephony solutions themselvesand simply want the rest of the operating-system functionality, and thosewho may not have a telephony application at all and want the operatingsystem they buy to offer a complete solution.This is, of course, not a design or engineering problem; it’s a businessproblem and there is no engineering solution to it.
What is the lesson?Andy Cloke:You should do an incremental design and you should also make sure that youhave an interested community both above and below the interface and that youinvolve them, that you validate the interface by continuing effort on it throughthe development process of the clients and the plug-ins on both sides, really toprevent yourself being circumvented wholly by those people. Especially whenyou have the same company building both the client and the plug-in. Becausethey will build assumptions into their client code which are fulfilled by theirplug-in code, but which are completely absent from the specifications.
And ofcourse they will extend it further than you would ever expect.15.5Messaging: It’s Different on a PhoneMessaging is another area which proved tricky in the transition tobeing a full-on phone-focused operating system. The Psion Series 5 wasMESSAGING: IT’S DIFFERENT ON A PHONE387specifically intended to provide integrated email and, in particular, to be‘Internet ready’, offering standard, Internet-based mail solutions, as wellas access to other Internet services.
Support for Internet-based email wastherefore an important design driver.Keith de Mendonca joined Psion in 1994 in one of the early, smallexpansions of the company which came with the success of the Series 3and the start of the preparations for the Series 5 project.Keith de Mendonca:I started with SDK work as a grounding, and I was working with Colly Myerson the Psion remote comms protocol SDK for the Psion Series 3a. Interestinglyenough, I remember getting a fax of appreciation from a small company inAmerica that I didn’t really know, a small company called Palm Computingthat it turned out we were in communication with about them perhaps writingconnectivity software.At around that time there was talk of cash-rich Psion buying Palm.But in the end Psion and Palm went their own ways.
Meanwhile, aftera stint writing applications for some of the later Series 3 machines, deMendonca moved to the new Messaging team.Keith de Mendonca:I think at the time it was the biggest team that Psion had ever had working ona single application.Its first task had been to create a messaging application for theSeries 3.Keith de Mendonca:On the Series 3 the focus had been on working just with corporate mail. It wasvery much before the real Internet explosion, so it was just bespoke.
It workedwith ccMail and I think one or two other mail clients. It was only later thatthere was a decision to go Internet, where the open standards were.For the Series 5, the team started from scratch with a new, modularand flexible messaging-client application which was designed to providea seamless, unified, single-point-of-access interface to email and othermessage types.388JUST ADD PHONEKeith de Mendonca:The intention for the Series 5 was very much that open standards were thefuture for us and the company. This was the most flexible way of actuallyinteracting with servers and hence getting the best market share. So all thework really was to do POP3 and SMTP and IMAP4, which we started doingfor the first time.
In addition to that it obviously did SMS and there was a faxcomponent as well, so you could send and receive faxes. So that was all inthe messaging application and the design of the application was informed bydiscussions that we had been having at the time with Nokia, because obviouslyin the background there had been lots of work thinking about what was to bein the Communicator.The Nokia Communicator project was already having an influence onthe design.
The ambition level was high.Keith de Mendonca:That was probably representative of the Nokia Communicator requirementsgenerally, that what everybody shipped in the end was much less than whatwe intended to do when the project was scoped at the very beginning. I thinkthe idea about what this next generation of communicator should do wasbeautiful and visionary, but the vision was very much greater than the realityof what both companies could produce in the time available.Messaging Design Goals and ArchitectureThe key design drivers were to support open standards, with a flexibleand extensible solution. The core of the design was a message storageframework for all messages, regardless of type, with plug-in protocolmodules for particular message types.
This was a modular solution, basedon sound object-oriented principles of abstraction from a generic notionof message to the individual message types, designed for openness andextensibility.Keith de Mendonca:You had one message store but you could actually plug in different modulesthat allowed you to add different messaging protocols as and when they cameup and even add those after market. So you could literally just download someSIS file and install some components, and suddenly you had fax or IMAP4support, for instance.
So the message architecture was designed from the verybeginning to be very modular and flexible and that is the architecture whichwe still have today.MESSAGING: IT’S DIFFERENT ON A PHONE389MTMsViewerSMSMTMEditorViewerEditorPOP3MTMViewerEditorIMAP4MTMViewerEditorOBEXMTMOther MTMs...Message store and frameworkStoreFilesystemUnderlyingsystemDiskFigure 15.7 Messaging architectureFollowing the general principle of Symbian OS design, access to themessage store is through a server, which offers a client-side API. The plugin modules (Message Type Modules or MTMs) are loaded dynamically bythe framework on demand, based on the type of the message, and handleeverything from the bitmap which is displayed in the inbox to indicate themessage type and status, to creating, copying, moving, deleting, parsingand editing contents of the message type.
See Figure 15.7.Keith de Mendonca:It also provided a back door for any special commands, which was literallyjust a special ID and any arguments that you chose to send to it in casethose generic ones didn’t actually represent what you were trying to do with aparticular message type.
The framework also allowed a simple API for anotherclient of that server, another application, to send content as a message andchoose the type dynamically based on the plug-ins which happened to be inthe framework at that time, the Send-As API.While the design met the stated requirements, the result was a largeand complex component with complex APIs. In at least one area, theflexibility of the application had an immediate pay-off. With the messagingapplication still not ready to ship on the final Series 5 launch date, themessaging architecture made it possible to ship a complete messagingpackage as a user-installable after-market upgrade. It duly shipped somemonths later.That flexibility proved just as useful for the first release of Nokia’s 9210Communicator.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
