1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/epoc32/include/mw/mtsr.h Wed Mar 31 12:27:01 2010 +0100
1.3 @@ -0,0 +1,504 @@
1.4 +// Copyright (c) 1998-2009 Nokia Corporation and/or its subsidiary(-ies).
1.5 +// All rights reserved.
1.6 +// This component and the accompanying materials are made available
1.7 +// under the terms of the License "Symbian Foundation License v1.0" to Symbian Foundation members and "Symbian Foundation End User License Agreement v1.0" to non-members
1.8 +// which accompanies this distribution, and is available
1.9 +// at the URL "http://www.symbianfoundation.org/legal/licencesv10.html".
1.10 +//
1.11 +// Initial Contributors:
1.12 +// Nokia Corporation - initial contribution.
1.13 +//
1.14 +// Contributors:
1.15 +//
1.16 +// Description:
1.17 +//
1.18 +
1.19 +#ifndef __MTSR_H__
1.20 +#define __MTSR_H__
1.21 +
1.22 +#include <e32base.h>
1.23 +#include <badesca.h>
1.24 +#include <msvstd.h>
1.25 +#include <msvreg.h>
1.26 +#include <tnonoperationmtmdata.h>
1.27 +
1.28 +// forward declarations
1.29 +class RWriteStream;
1.30 +class RReadStream;
1.31 +class RFs;
1.32 +class CDictionaryFileStore;
1.33 +class CInstalledMtmGroup;
1.34 +class CMsvServerEntry;
1.35 +class TMsvSystemProgress;
1.36 +
1.37 +class CBaseServerMtm : public CActive
1.38 +/** Base class for Server-side MTM components. Server-side MTMs provide all message
1.39 +transport functionality for a particular messaging protocol.
1.40 +
1.41 +MTM implementers implement a derived class to provide such functionality for
1.42 +their message protocol. Writers of message client applications are never concerned
1.43 +with this class and its sub-classes, as these are only accessed by the Message
1.44 +Server.
1.45 +
1.46 +Each MTM interprets the generic commands in different ways. For example, a
1.47 +Fax MTM would transmit a fax when asked to copy a fax from a local folder
1.48 +to a fax service. For the same function, an IMAP MTM would create a copy of
1.49 +the message on the remote server and update the message index to show the
1.50 +copy of the message on the remote server. An important initial design task
1.51 +is to the map the functions to the functionality provided by the protocol.
1.52 +
1.53 +Server-side MTM functions are called by the Message Server as a result of
1.54 +a client request that requires some remote operation with the MTM's protocol.
1.55 +The following steps give a simplified view of the usual sequence of events:
1.56 +
1.57 +1. the Message Server instantiates a Server-side MTM object through the factory
1.58 +function
1.59 +
1.60 +2. the Message Server calls the appropriate asynchronous function on the Server-side
1.61 +MTM interface, passing a TRequestStatus argument
1.62 +
1.63 +3. the Server-side MTM function typically starts whatever asynchronous communications
1.64 +it requires and returns
1.65 +
1.66 +4. the Server-side MTM is signalled when the asynchronous communications complete,
1.67 +and handles the result
1.68 +
1.69 +5. the Server-side MTM signals the Message Server, through the TRequestStatus
1.70 +passed earlier
1.71 +
1.72 +6. the Message Server deletes the Server-side MTM object
1.73 +
1.74 +To qualify this somewhat:
1.75 +
1.76 +1. it is up to the Server-side MTM implementation to decide how to translate
1.77 +data back and forth between the formats used by Message Server (index entry,
1.78 +message store, binary files), and that required by the protocol; this is another
1.79 +important design task
1.80 +
1.81 +2. depending on the protocol being used, the communications sequence can be of
1.82 +considerable complexity; typically it requires division into a number of asynchronous
1.83 +steps
1.84 +
1.85 +3. for greater efficiency where further commands are shortly expected, deletion
1.86 +of the Server-side MTM object can be prevented
1.87 +
1.88 +For asynchronous requests, a Server-side MTM should always complete the TRequestStatus
1.89 +with KErrNone. Any errors should be returned in the progress information.
1.90 +
1.91 +Note the following significant groups of functions:
1.92 +
1.93 +1. Copy and move from remote functions: CopyToLocalL() and MoveToLocalL() are
1.94 +called by the Message Server to get a selection of entries from a remote location.
1.95 +For many protocols, this should be interpreted as message retrieval. For protocols
1.96 +where messages exist on a remote server, this function is typically used to
1.97 +download specific messages, after an initial connection has downloaded message
1.98 +headers.
1.99 +
1.100 +2. Copy and move to remote functions: CopyFromLocalL() and MoveFromLocalL() are
1.101 +called by the Message Server to copy/move a selection of entries to a remote
1.102 +location. For many protocols, this should be interpreted as message sending.
1.103 +
1.104 +3. Copy and move within remote functions: CopyWithinServiceL() and MoveWithinServiceL()
1.105 +are called by the Message Server to copy a selection of entries within a remote
1.106 +service. An example of their use might be for a user rearranging messages
1.107 +within remote folders.
1.108 +@publishedAll
1.109 +@released
1.110 +*/
1.111 + {
1.112 +public:
1.113 + IMPORT_C ~CBaseServerMtm();
1.114 + //
1.115 + /** Copies a selection of entries from a remote location to a local location. This
1.116 + will only be meaningful for some protocols.
1.117 +
1.118 + Requirements:
1.119 +
1.120 + Implementations should provide this function if the messaging protocol supports
1.121 + retrieval of remote entries. If this is not supported, implementations should
1.122 + leave with KErrNotSupported.
1.123 +
1.124 + Implementations of this function have three fundamental steps:
1.125 +
1.126 + 1. doing the transfer operation using the appropriate communications protocols
1.127 +
1.128 + 2. converting protocol-specific data into the three-part storage format (index
1.129 + entry, message store, binary files) required by the Message Server
1.130 +
1.131 + 3. updating entries in the Message Server
1.132 +
1.133 + @param aSelection The collection of message index entries for which the copy/moving
1.134 + is required.
1.135 + @param aDestination The entry ID to which the selection is to be copied
1.136 + @param aStatus Asynchronous completion word for the operation
1.137 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.138 + @leave Other leave codes Dependent on implementation */
1.139 + virtual void CopyToLocalL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.140 + /** Copies a selection of entries from a local location to a remote location.
1.141 +
1.142 + Requirements:
1.143 +
1.144 + Implementations should provide this function if the messaging protocol supports
1.145 + retrieval of remote entries. If this is not supported, implementations should
1.146 + leave with KErrNotSupported.
1.147 +
1.148 + Implementations of this function have three fundamental steps:
1.149 +
1.150 + 1. reading entry data
1.151 +
1.152 + 2. converting entry data from the Message Server format into that required by
1.153 + the protocol
1.154 +
1.155 + 3. doing the transfer operation using the appropriate communications protocols
1.156 +
1.157 + @param aSelection The collection of message index entries for which the copy
1.158 + is required
1.159 + @param aDestination The entry ID of the service by which the entries should
1.160 + be transferred
1.161 + @param aStatus Asynchronous completion word for the operation
1.162 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.163 + @leave Other leave codes Dependent on implementation */
1.164 + virtual void CopyFromLocalL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.165 + /** Copies a selection of entries within a remote location.
1.166 +
1.167 + Requirements:
1.168 +
1.169 + Implementations should provide this function if the messaging protocol supports
1.170 + the ability to copy entries within a remote service. If this is not supported,
1.171 + implementations should leave with KErrNotSupported.
1.172 +
1.173 + @param aSelection The collection of message index entries for which the copy
1.174 + is required
1.175 + @param aDestination The server entry ID to which the selection is to be copied
1.176 + @param aStatus Asynchronous completion word for the operation
1.177 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.178 + @leave Other leave codes Dependent on implementation */
1.179 + virtual void CopyWithinServiceL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.180 + /** Deletes each entry in the supplied selection when called by the message Server.
1.181 + If any of the entries in the selection is a parent entry, then all its children
1.182 + should also be deleted, recursively to the bottom of the ownership tree.
1.183 +
1.184 + Implementations should provide this function if the messaging protocol supports
1.185 + deletion of remote entries. If this is not supported, implementations should
1.186 + leave with KErrNotSupported.
1.187 +
1.188 + @param aSelection The collection of entries that are to be deleted.
1.189 + @param aStatus Asynchronous completion object.
1.190 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.191 + @leave Other leave codes Dependent on implementation */
1.192 + virtual void DeleteAllL(const CMsvEntrySelection& aSelection, TRequestStatus& aStatus)=0;
1.193 + /** Creates a new remote entry with relevant data when called by the Message Server.
1.194 +
1.195 + Implementations should provide this function if the messaging protocol supports
1.196 + creation of remote entries. If this is not supported, implementations should
1.197 + leave with KErrNotSupported.
1.198 +
1.199 + As with ChangeL(), the Server-side MTM implementation must decide what information
1.200 + in the TMsvEntry is relevant to the remote entry, and translate it appropriately
1.201 + for the specific protocol. Most of the data contained in the TMsvEntry is
1.202 + specific to the Message Server, and would probably have no direct correlation
1.203 + with the protocol's own storage format. For example, for a folder, probably
1.204 + only the name and parent are needed, so if the protocol supports creation
1.205 + of remote folders, the implementation could:
1.206 +
1.207 + 1. check for a folder type entry
1.208 +
1.209 + 2. get the folder name and parent details from aNewEntry
1.210 +
1.211 + 3. initiate a protocol-specific action to create the remote folder
1.212 +
1.213 + @param aNewEntry Data by which to create entry
1.214 + @param aStatus Asynchronous completion word for the operation.
1.215 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.216 + @leave Other leave codes Dependent on implementation */
1.217 + virtual void CreateL(TMsvEntry aNewEntry, TRequestStatus& aStatus)=0;
1.218 + /** Updates a remote entry with relevant data when called by the Message Server.
1.219 +
1.220 + Implementations should provide this function if the messaging protocol supports
1.221 + updating of remote entries. If this is not supported, implementations should
1.222 + leave with KErrNotSupported.
1.223 +
1.224 + The Server-side MTM implementation must decide what information in the TMsvEntry
1.225 + is relevant to the remote entry, and translate it appropriately for the specific
1.226 + protocol. Most of the data contained in the TMsvEntry is specific to the Symbian
1.227 + OS Message Server, and would probably have no direct correlation with the
1.228 + protocol's own storage format. Some entry data may however be useful. For
1.229 + example, if the protocol supports remote renaming of folders, the implementation
1.230 + could:
1.231 +
1.232 + 1. check for a folder type entry
1.233 +
1.234 + 2. extract the folder name from aNewEntry.iDetails
1.235 +
1.236 + 3. check if the folder name has changed by comparing the new name with iDetails
1.237 + in the index entry currently; if not, complete with KErrNone
1.238 +
1.239 + 4. initiate a protocol-specific action to rename the remote folder
1.240 +
1.241 + The implementation should also always update the local Message Server index
1.242 + through CMsvServerEntry::ChangeL().
1.243 +
1.244 + @param aNewEntry Data by which to update entry
1.245 + @param aStatus Asynchronous completion word for the operation.
1.246 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.247 + @leave Other leave codes Dependent on implementation */
1.248 + virtual void ChangeL(TMsvEntry aNewEntry, TRequestStatus& aStatus)=0;
1.249 + //
1.250 + /** Executes an MTM-specific operation on a selection of entries when called by
1.251 + the Message Server.
1.252 +
1.253 + The call is made as a response to a client program invoking an MTM-specific
1.254 + operation through CBaseMtm::InvokeSyncFunctionL()/InvokeAsyncFunctionL().
1.255 + The aSelection, aCommand, and aParameter arguments pass the values of the
1.256 + original aSelection, aFunctionId, and aParameter respectively arguments from
1.257 + such a call. The use (if any) of the aSelection and aParameter arguments by
1.258 + the function depends on the command.
1.259 +
1.260 + @param aSelection A selection of message entries on which the command is to
1.261 + be executed
1.262 + @param aCommand The MTM-specific command to be carried out
1.263 + @param aParameter Command-specific parameters
1.264 + @param aStatus Asynchronous completion word for the operation */
1.265 + virtual void StartCommandL(CMsvEntrySelection& aSelection, TInt aCommand, const TDesC8& aParameter, TRequestStatus& aStatus)=0;
1.266 + //
1.267 + /** Tests if the Server-side MTM object should be deleted when called by the Message
1.268 + Server
1.269 +
1.270 + It is useful to stop the MTM being deleted when more commands are expected
1.271 + shortly. This would be the case, for example, after receiving a command to
1.272 + go online.
1.273 +
1.274 + If there are no more commands expected by the Server-side MTM object, then
1.275 + the function should return EFalse, and the Message Server will delete it.
1.276 +
1.277 + @return ETrue: the MTM object should not be deleted EFalse: the MTM object
1.278 + can be deleted */
1.279 + virtual TBool CommandExpected()=0;
1.280 + //
1.281 + /** This function is called by the Message Server to get progress information for
1.282 + the current asynchronous operation.
1.283 +
1.284 + The call is made as a response to a client program requesting progress information
1.285 + through CMsvOperation::ProgressL(). The packing format used in the TDesC8
1.286 + is MTM-specific. Only the implementation of the User Interface MTM progress
1.287 + information functions need to understand the format.
1.288 +
1.289 + The progress buffer should have a maximum size of 256 bytes.
1.290 +
1.291 + @return Progress information on current asynchronous operation
1.292 + @see CBaseMtmUi::DisplayProgressSummary()
1.293 + @see CBaseMtmUi::GetProgress() */
1.294 + virtual const TDesC8& Progress()=0;
1.295 + //
1.296 + /** Moves a selection of entries from a remote location to a local location.
1.297 +
1.298 + Requirements:
1.299 +
1.300 + Implementations should provide this function if the messaging protocol supports
1.301 + retrieval of remote entries. If this is not supported, implementations should
1.302 + leave with KErrNotSupported.
1.303 +
1.304 + Implementations of this function have three fundamental steps:
1.305 +
1.306 + 1. doing the transfer operation using the appropriate communications protocols
1.307 +
1.308 + 2. converting protocol-specific data into the three-part storage format (index
1.309 + entry, message store, binary files) required by the Message Server
1.310 +
1.311 + 3. updating entries in the Message Server
1.312 +
1.313 + MoveToLocalL() should differ from CopyToLocalL() in additionally deleting
1.314 + the original remote data.
1.315 +
1.316 + @param aSelection The collection of message index entries for which the moving
1.317 + is required.
1.318 + @param aDestination The entry ID to which the selection is to be copied/moved
1.319 + @param aStatus Asynchronous completion word for the operation
1.320 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.321 + @leave Other leave codes Dependent on implementation */
1.322 + virtual void MoveToLocalL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.323 + /** Moves a selection of entries from a local location to a remote location.
1.324 +
1.325 + Requirements:
1.326 +
1.327 + Implementations should provide this function if the messaging protocol supports
1.328 + retrieval of remote entries. If this is not supported, implementations should
1.329 + leave with KErrNotSupported.
1.330 +
1.331 + Implementations of this function have three fundamental steps:
1.332 +
1.333 + 1. reading entry data
1.334 +
1.335 + 2. converting entry data from the Message Server format into that required by
1.336 + the protocol
1.337 +
1.338 + 3. doing the transfer operation using the appropriate communications protocols
1.339 +
1.340 + The implementation of MoveFromLocalL() should differ from CopyFromLocalL()
1.341 + in additionally deleting the original local data.
1.342 +
1.343 + @param aSelection The collection of message index entries for which the move
1.344 + is required
1.345 + @param aDestination The entry ID of the service by which the entries should
1.346 + be transferred
1.347 + @param aStatus Asynchronous completion word for the operation
1.348 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.349 + @leave Other leave codes Dependent on implementation */
1.350 + virtual void MoveFromLocalL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.351 + /** Moves a selection of entries within a remote location.
1.352 +
1.353 + Requirements:
1.354 +
1.355 + Implementations should provide this function if the messaging protocol supports
1.356 + the ability to move entries within a remote service. If this is not supported,
1.357 + implementations should leave with KErrNotSupported.
1.358 +
1.359 + The implementation of MoveWithinServiceL() should differ from CopyWithinServiceL()
1.360 + in additionally deleting the original data.
1.361 +
1.362 + @param aSelection The collection of message index entries for which the move
1.363 + is required
1.364 + @param aDestination The server entry ID to which the selection is to be moved
1.365 + @param aStatus Asynchronous completion word for the operation
1.366 + @leave KErrNotSupported The Server-side MTM does not support this operation
1.367 + @leave Other leave codes Dependent on implementation */
1.368 + virtual void MoveWithinServiceL(const CMsvEntrySelection& aSelection,TMsvId aDestination, TRequestStatus& aStatus)=0;
1.369 +
1.370 + IMPORT_C TInt SystemProgress(TMsvSystemProgress& aOutSysProg);
1.371 + TInt GetNonOperationMtmData(TNonOperationMtmDataType& aMtmDataType, TPtrC8& aResultBuffer);
1.372 +
1.373 +protected:
1.374 + IMPORT_C CBaseServerMtm(CRegisteredMtmDll& aRegisteredMtmDll, CMsvServerEntry* aServerEntry);
1.375 + /** Handles the completion of any asynchronous requests that it makes. It is called
1.376 + from the base class RunL() .
1.377 +
1.378 + Note that any leaves made by this function result in DoComplete() being called
1.379 + with the leave code. */
1.380 + virtual void DoRunL()=0;
1.381 + /** Called by the base class RunL() if DoRunL() leaves.
1.382 +
1.383 + It should be implemented to handle this error. For example, progress information
1.384 + could be updated to reflect the problem.
1.385 +
1.386 + @param aError The leave code given by DoRunL(). */
1.387 + virtual void DoComplete(TInt aError)=0;
1.388 + //
1.389 + IMPORT_C TInt Extension_(TUint aExtensionId, TAny *&a0, TAny *a1);
1.390 + //
1.391 +private:
1.392 + // from CActive
1.393 + IMPORT_C void RunL();
1.394 + IMPORT_C TInt RunError(TInt aError);
1.395 + //
1.396 +protected:
1.397 + /** The entry on which to operate. It is set in the constructor.
1.398 +
1.399 + The destructor deletes this member. */
1.400 + CMsvServerEntry* iServerEntry;
1.401 +
1.402 + // Method used for extension: called by non virtual methods that need
1.403 + // to have a polymorphic behaviour.
1.404 + IMPORT_C virtual TAny* GetInterface(TUid aUid);
1.405 + //
1.406 +private:
1.407 + CRegisteredMtmDll& iRegisteredMtmDll;
1.408 +
1.409 +private:
1.410 + // Extra data member to allow for future extensions
1.411 + TAny* iExtensionData;
1.412 + };
1.413 +
1.414 +
1.415 +class CServerMtmDllRegistry : public CMtmDllRegistry
1.416 +/**
1.417 +@publishedAll
1.418 +@released
1.419 +*/
1.420 + {
1.421 +friend class CMtmRegistryControl;
1.422 +public:
1.423 + IMPORT_C static CServerMtmDllRegistry* NewL(RFs& aFs,TTimeIntervalMicroSeconds32 aTimeoutMicroSeconds32=KMsvDefaultTimeoutMicroSeconds32);
1.424 + IMPORT_C ~CServerMtmDllRegistry();
1.425 + IMPORT_C CBaseServerMtm* NewServerMtmL(TUid aMtmTypeUid, CMsvServerEntry* aInitialEntry);
1.426 + //
1.427 +protected:
1.428 + CServerMtmDllRegistry(RFs& aFs,TTimeIntervalMicroSeconds32 aTimeoutMicroSeconds32);
1.429 + //
1.430 +private:
1.431 + CBaseServerMtm* NewMtmL(const RLibrary& aLib, CMsvServerEntry* aServerEntry, CRegisteredMtmDll& aReg) const;
1.432 + };
1.433 +
1.434 +
1.435 +class CInstalledMtmGroupArray : public CArrayPtrFlat<CInstalledMtmGroup>
1.436 +/**
1.437 +@internalComponent
1.438 +@released
1.439 +*/
1.440 + {
1.441 +public:
1.442 + CInstalledMtmGroupArray();
1.443 + ~CInstalledMtmGroupArray();
1.444 + void AddInstalledMtmGroupL(CInstalledMtmGroup* aInstalledMtmGroup);
1.445 + };
1.446 +
1.447 +//**********************************
1.448 +// CMsvMtmCache
1.449 +//**********************************
1.450 +
1.451 +
1.452 +//**********************************
1.453 +// CMtmRegistryControl
1.454 +//**********************************
1.455 +
1.456 +class CMtmRegistryControl : public CBase, public MRegisteredMtmDllObserver
1.457 +/**
1.458 +@publishedAll
1.459 +@released
1.460 +*/
1.461 + {
1.462 +public:
1.463 + IMPORT_C static CMtmRegistryControl* NewL(RFs& anFs,CServerMtmDllRegistry& aServerMtmDllRegistry);
1.464 + IMPORT_C ~CMtmRegistryControl();
1.465 +
1.466 + IMPORT_C TInt InstallMtmGroup(const TDesC& aFullName,TUid& aMtmTypeUid);
1.467 + IMPORT_C TInt FullNameToMtmTypeUid(const TDesC& aFullName,TUid& aMtmTypeUid) const;
1.468 + IMPORT_C TInt DeInstallMtmGroup(TUid aMtmTypeUid); // returns error on storing registry
1.469 +
1.470 + IMPORT_C TInt UseMtmGroup(TUid aMtmTypeUid);
1.471 + IMPORT_C TInt ReleaseMtmGroup(TUid aMtmTypeUid);
1.472 + IMPORT_C TBool IsInUse(TUid aMtmTypeUid) const;
1.473 +
1.474 + IMPORT_C TInt FillRegisteredMtmDllArray(TUid aMtmDllTypeUid,CRegisteredMtmDllArray& aRegisteredMtmDllArray,TTimeIntervalMicroSeconds32 aTimeoutMicroSeconds32=0); // Fill array with Dlls whose second uid is aMtmDllTypeUid
1.475 + IMPORT_C CMtmGroupData* GetMtmGroupDataL(TUid aMtmTypeUid) const;
1.476 + const CMtmGroupData& GetMtmGroupDataReferenceL(TUid aMtmTypeUid) const;
1.477 +
1.478 + IMPORT_C void StoreRegistryL() const;
1.479 + IMPORT_C void RestoreRegistryL();
1.480 +
1.481 + IMPORT_C void InternalizeL(RReadStream& aStream);
1.482 + IMPORT_C void ExternalizeL(RWriteStream& aStream) const;
1.483 +
1.484 +private:
1.485 + CMtmRegistryControl(RFs& anFs,CServerMtmDllRegistry& aServerMtmDllRegistry);
1.486 + void ConstructL();
1.487 + TInt MtmTypeUidToIndex(TUid aMtmTypeUid) const;
1.488 + TInt UidTypeToIndex(TUidType aUidType) const;
1.489 + void DoInstallMtmGroupL(const TDesC& aFullName,TUid& aMtmTypeUid);
1.490 + CMtmGroupData* ReadDataFileStoreL(const TDesC& aFullName) const;
1.491 + void DoDeInstallMtmGroupL(TUid aMtmTypeUid);
1.492 + void DoInternalizeL(RReadStream& aStream);
1.493 + void AddInstalledMtmGroupL(CInstalledMtmGroup* aInstalledMtmGroup);
1.494 + void RemoveInstalledMtmGroup(TUid aMtmTypeUid);
1.495 + TBool IsResFileL(const TDesC& aFullName) const;
1.496 + TUid DoFindMtmTypeUidL(const TDesC& aFullName) const;
1.497 +
1.498 + CMtmGroupData *LoadMTMFileL(const TDesC& aFullName, TUid &aUid);
1.499 + CMtmGroupData *LoadDatFileL(const TDesC& aFullName, TUid &aUid);
1.500 + CMtmGroupData *LoadResFileL(const TDesC& aFullName, TUid &aUid);
1.501 +private:
1.502 + RFs& iFs;
1.503 + CInstalledMtmGroupArray iInstalledMtmGroupArray;
1.504 + CServerMtmDllRegistry& iServerMtmDllRegistry;
1.505 + };
1.506 +
1.507 +#endif // __MTSR_H__