|
1 // Copyright (c) 2006-2009 Nokia Corporation and/or its subsidiary(-ies). |
|
2 // All rights reserved. |
|
3 // This component and the accompanying materials are made available |
|
4 // under the terms of "Eclipse Public License v1.0" |
|
5 // which accompanies this distribution, and is available |
|
6 // at the URL "http://www.eclipse.org/legal/epl-v10.html". |
|
7 // |
|
8 // Initial Contributors: |
|
9 // Nokia Corporation - initial contribution. |
|
10 // |
|
11 // Contributors: |
|
12 // |
|
13 // Description: |
|
14 // |
|
15 |
|
16 /** |
|
17 @file |
|
18 @internalTechnology |
|
19 */ |
|
20 |
|
21 #ifndef CMTPPARSERROUTER_H |
|
22 #define CMTPPARSERROUTER_H |
|
23 |
|
24 #include <e32cmn.h> |
|
25 #include <mtp/tmtptyperequest.h> |
|
26 |
|
27 #include "cmtpdataprovidercontroller.h" |
|
28 #include "mtpdebug.h" |
|
29 #include "rmtpframework.h" |
|
30 |
|
31 class CMTPConnection; |
|
32 class CMTPDataProvider; |
|
33 class MMTPConnection; |
|
34 class TMTPTypeEvent; |
|
35 |
|
36 /** |
|
37 Implements the MTP framework parser/router singleton. |
|
38 |
|
39 The MTP framework parser/router singleton is responsible for directing received |
|
40 MTP operation request (and event) datasets to the appropriate data provider(s) |
|
41 for processing, and performs the following major functions: |
|
42 |
|
43 1. Parses received operation request and event datasets to extract and |
|
44 coarse grain validate routing data (@see ParseOperationRequestL). |
|
45 2. Executes one or more routing algorithms to select the set of data |
|
46 provider targets able to service the operation or event |
|
47 (@see RouteOperationRequestL). |
|
48 3. (Optionally) dispatches the request or event (@see ProcessRequestL). |
|
49 |
|
50 There are two basic scenarios which the parser/router must handle, and a |
|
51 different set of APIs is provided for each. These scenarios are: |
|
52 |
|
53 1. The initial routing of operations as they are first received. This |
|
54 routing is initiated by the MTP framework using the @see ProcessRequestL |
|
55 API. This API executes all three of the functions identified above. |
|
56 2. The secondary routing of those operations which cannot be dispatched |
|
57 directly. Either because they require the combined processing |
|
58 capabilities of multiple data providers to produce an aggregated |
|
59 response, or; because they cannot be routed using data available during |
|
60 the operation request phase and can only be routed to their final |
|
61 target using data available during the operation data phase. This |
|
62 secondary routing is performed by the MTP framework's proxy data |
|
63 provider using the @see ParseOperationRequestL and |
|
64 @see RouteOperationRequestL APIs. These APIs respectively execute the |
|
65 first two functions identified above, which are separated in order to |
|
66 allow additional information to be added to the routing data by the |
|
67 proxy data provider. The third function identified above is not executed |
|
68 in this scenario, since a very different dispatching mechanism must be |
|
69 used by the proxy data provider. |
|
70 |
|
71 The parser/router implements a number of different routing algorithm types, |
|
72 some of which are further decomposed into sub-types to achieve a finer level of |
|
73 routing granularity and control. In combination these algorithms support the |
|
74 following general routing mechanisms: |
|
75 |
|
76 1. Device - A subset of device oriented MTP operations are always |
|
77 dispatched to the device data provider. |
|
78 2. Proxy - A subset of MTP operations cannot be dispatched directly. |
|
79 Either they require the combined processing capabilities of multiple |
|
80 data providers to produce an aggregated response, or cannot be routed |
|
81 using data available from the operation dataset alone. These operations |
|
82 are dispatched to the proxy data provider for additional processing. |
|
83 3. Object Handle - MTP object handles generated by the MTP framework are |
|
84 encoded with a data provider identifier to efficiently route those MTP |
|
85 operations which supply an object handle as a parameter. |
|
86 4. StorageID - MTP storage identifiers generated by the MTP framework are |
|
87 encoded with a data provider identifier to efficiently route those MTP |
|
88 operations which supply a storage identifier as a parameter. |
|
89 5. Operation Parameter - On being loaded each data provider supplies a set |
|
90 of configuration data (MTP operation codes, event codes, object |
|
91 property codes, device property codes, and storage system types) which |
|
92 collectively define the set of MTP operation requests that it wishes to |
|
93 receive. |
|
94 6. Request Registration - Data providers may optionally register MTP |
|
95 operation request datasets with the framework which, when subsequently |
|
96 matched, will be routed to them. This mechanism is used to route those |
|
97 MTP operation types which are paired to complete over two transaction |
|
98 cycles (e.g. SendObjectInfo/SendObject). It may also be used to route |
|
99 vendor extension operation requests. |
|
100 |
|
101 The following routing algorithm types are implemeted: |
|
102 |
|
103 1. Operation Parameter Routing |
|
104 |
|
105 Operation parameter routing is the primary routing mechanism and by |
|
106 default is enabled for both initial and secondary proxy routing |
|
107 scenarios. Operation parameter routing involves selecting one or more |
|
108 data provider targets using routing data obtained from or related to |
|
109 the supplied operation dataset parameters using one of the following |
|
110 sub-types: |
|
111 |
|
112 o Parameter lookup routing sub-types, which match operation dataset |
|
113 parameter data with the set of supported capabilities registered |
|
114 by each data provider on being loaded, or; |
|
115 o Parameter decode routing sub-types, which extract data provider |
|
116 target identifiers encoded into the parameter data itself. |
|
117 |
|
118 The parameter lookup routing sub-types are table driven and utilise |
|
119 binary search techniques to minimise processing overhead. The |
|
120 following parameter lookup routing sub-types (tables) are implemented, |
|
121 each characterised by the combination of parameters they require to map |
|
122 to a routing target: |
|
123 |
|
124 o DevicePropCode |
|
125 o ObjectPropCode |
|
126 o OperationCode |
|
127 o StorageType |
|
128 o FormatCode + FormatSubcode |
|
129 o FormatCode + OperationCode |
|
130 o StorageType + OperationCode |
|
131 o FormatCode + FormatSubcode + StorageType |
|
132 |
|
133 These routing tables may be further characterised by modifier flags |
|
134 which e.g. allow or disallow duplicate entries, or specify ascending |
|
135 or descending sort orders which in turn can manipulate the order in |
|
136 which proxy targets are processed. |
|
137 |
|
138 The parameter decode routing sub-types extract routing target |
|
139 identifiers directly from the operation dataset parameter data itself. |
|
140 The following parameter decode routing sub-types are implemented: |
|
141 |
|
142 o Object Handle |
|
143 o StorageID |
|
144 |
|
145 2. Framework Routing |
|
146 |
|
147 By default, framework routing is enabled during initial operation |
|
148 routing only and not during secondary proxy routing. Framework routing |
|
149 directs a sub-set of MTP operations to one or other of the framework |
|
150 data providers. Using one of the following routing sub-types: |
|
151 |
|
152 o Device DP. A fixed sub-set of MTP operations are always dispatched |
|
153 to the device data provider. |
|
154 o Proxy DP. A fixed sub-set of MTP operations are always dispatched |
|
155 to the proxy data provider. In addition, any operations which yield |
|
156 multiple routing targets will also be routed to the proxy data |
|
157 provider. |
|
158 |
|
159 3. Request Registration Routing |
|
160 |
|
161 By default, request registration routing is enabled during initial |
|
162 operation routing only and not during secondary proxy routing. Data |
|
163 providers may optionally register MTP operation request datasets with |
|
164 the framework which, when subsequently matched, will be routed to them. |
|
165 This mechanism is used to process those MTP operation types which are |
|
166 paired to complete over two transaction cycles (e.g. |
|
167 SendObjectInfo/SendObject). It may also be used to route vendor |
|
168 extension operation requests. |
|
169 |
|
170 Request registration routing does not implement any routing sub-types. |
|
171 |
|
172 @internalTechnology |
|
173 |
|
174 */ |
|
175 class CMTPParserRouter : public CBase |
|
176 { |
|
177 public: |
|
178 |
|
179 /** |
|
180 Defines the MTP operation routing parameter data, which is an output of the |
|
181 parser/routers @see ParseOperationRequestL API and an input to the |
|
182 @see RouteOperationRequestL API. |
|
183 */ |
|
184 class TRoutingParameters |
|
185 { |
|
186 public: |
|
187 |
|
188 /** |
|
189 The routing parameter type identifiers. Note that not all parameter |
|
190 types may be defined, only those deemed necessary to route the |
|
191 associated operation dataset. |
|
192 */ |
|
193 enum TParameterType |
|
194 { |
|
195 /** |
|
196 The DevicePropCode parameter. |
|
197 */ |
|
198 EParamDevicePropCode, |
|
199 |
|
200 /** |
|
201 The object FormatCode parameter. |
|
202 */ |
|
203 EParamFormatCode, |
|
204 |
|
205 /** |
|
206 The object format sub-code parameter. This parameter is undefined |
|
207 unless @see EFormatCode contains a value of |
|
208 @see EMTPFormatCodeAssociation, in which case this parameter should |
|
209 the specify the MTP association type code. |
|
210 */ |
|
211 EParamFormatSubCode, |
|
212 |
|
213 /** |
|
214 The ObjectHandle parameter. |
|
215 */ |
|
216 EParamObjectHandle, |
|
217 |
|
218 /** |
|
219 The ObjectPropCode parameter. |
|
220 */ |
|
221 EParamObjectPropCode, |
|
222 |
|
223 /** |
|
224 The StorageId parameter. |
|
225 */ |
|
226 EParamStorageId, |
|
227 |
|
228 /** |
|
229 The storage system type parameter. |
|
230 */ |
|
231 EParamStorageSystemType, |
|
232 |
|
233 /** |
|
234 The invalid dataset flag. When set, this flag indicates that an |
|
235 operation dataset validation check failed. |
|
236 */ |
|
237 EFlagInvalid, |
|
238 |
|
239 /** |
|
240 The routing type codes. This flag is intended for internal use |
|
241 only. |
|
242 */ |
|
243 EFlagRoutingTypes, |
|
244 |
|
245 /** |
|
246 The ServiceID parameter. |
|
247 */ |
|
248 EParamServiceId, |
|
249 |
|
250 /** |
|
251 */ |
|
252 ENumTypes |
|
253 }; |
|
254 |
|
255 public: |
|
256 |
|
257 IMPORT_C TRoutingParameters(const TMTPTypeRequest& aRequest, MMTPConnection& aConnection); |
|
258 TRoutingParameters(const TRoutingParameters& aParams); |
|
259 |
|
260 IMPORT_C MMTPConnection& Connection() const; |
|
261 IMPORT_C TUint Param(TParameterType aId) const; |
|
262 IMPORT_C void Reset(); |
|
263 IMPORT_C const TMTPTypeRequest& Request() const; |
|
264 IMPORT_C void SetParam(TParameterType aId, TUint aVal); |
|
265 |
|
266 private: // Not owned |
|
267 |
|
268 /** |
|
269 The handle of the MTP connection on which the operation is being |
|
270 processed. |
|
271 */ |
|
272 MMTPConnection& iConnection; |
|
273 |
|
274 /** |
|
275 The operation dataset. |
|
276 */ |
|
277 const TMTPTypeRequest& iRequest; |
|
278 |
|
279 private: // Owned |
|
280 |
|
281 TUint iParameterData[ENumTypes]; |
|
282 TFixedArray<TUint, ENumTypes> iParameters; |
|
283 }; |
|
284 |
|
285 public: |
|
286 |
|
287 static CMTPParserRouter* NewL(); |
|
288 virtual ~CMTPParserRouter(); |
|
289 |
|
290 IMPORT_C void ConfigureL(); |
|
291 IMPORT_C TBool OperationSupportedL(TUint16 aOperation) const; |
|
292 IMPORT_C void ParseOperationRequestL(TRoutingParameters& aParams) const; |
|
293 IMPORT_C void RouteOperationRequestL(const TRoutingParameters& aParams, RArray<TUint>& aTargets) const; |
|
294 IMPORT_C TBool RouteRequestRegisteredL(const TMTPTypeRequest& aRequest, MMTPConnection& aConnection) const; |
|
295 |
|
296 void ProcessEventL(const TMTPTypeEvent& aEvent, CMTPConnection& aConnection) const; |
|
297 void ProcessRequestL(const TMTPTypeRequest& aRequest, CMTPConnection& aConnection) const; |
|
298 void RouteRequestRegisterL(const TMTPTypeRequest& aRequest, MMTPConnection& aConnection, TInt aId); |
|
299 void RouteRequestUnregisterL(const TMTPTypeRequest& aRequest, MMTPConnection& aConnection); |
|
300 |
|
301 private: // Owned |
|
302 |
|
303 /** |
|
304 Defines the routing type codes. These codes are partitioned into |
|
305 two sub-fields as follows: |
|
306 |
|
307 1. Bits 0-15 - routing type identifier. |
|
308 2. Bits 16-23 - unused. |
|
309 3. Bits 24-31 - routing type modifier flags. |
|
310 */ |
|
311 enum TRoutingType |
|
312 { |
|
313 /** |
|
314 The routing type modifier flags mask. |
|
315 */ |
|
316 ETypeFlagMask = 0xFF000000, |
|
317 |
|
318 /** |
|
319 The single target flag. When set this flag will result in at most one |
|
320 eligible routing target being selected. If multiple eligible targets |
|
321 exists then the first eligible target will be selected. |
|
322 */ |
|
323 ETypeFlagSingleTarget = 0x01000000, |
|
324 |
|
325 /** |
|
326 The routing type identifier mask. |
|
327 */ |
|
328 ETypeMask = 0x0000FFFF, |
|
329 |
|
330 /** |
|
331 The framework routing type identifier. |
|
332 */ |
|
333 ETypeFramework = 0x00000001, |
|
334 |
|
335 /** |
|
336 The operation parameter routing type identifier. |
|
337 */ |
|
338 ETypeOperationParameter = 0x00000002, |
|
339 |
|
340 /** |
|
341 The request registration routing type identifier. |
|
342 */ |
|
343 ETypeRequestRegistration = 0x00000004, |
|
344 }; |
|
345 |
|
346 /** |
|
347 Defines the routing sub-type codes. These codes are partitioned into |
|
348 two sub-fields as follows: |
|
349 |
|
350 1. Bits 0-15 - routing sub-type (map) index. |
|
351 2. Bits 16-23 - routing sub-type modifier flags. |
|
352 3. Bits 24-31 - routing sub-type parameter count type. |
|
353 */ |
|
354 enum TRoutingSubType |
|
355 { |
|
356 /** |
|
357 The routing sub-type identifier (table index) mask. |
|
358 */ |
|
359 ESubTypeIndexMask = 0x0000FFFF, |
|
360 |
|
361 /** |
|
362 The routing sub-type modifier bit flags mask. |
|
363 */ |
|
364 ESubTypeFlagMask = 0x00FF0000, |
|
365 |
|
366 /** |
|
367 The null flag bits. |
|
368 */ |
|
369 ESubTypeFlagNone = 0x00000000, |
|
370 |
|
371 /** |
|
372 The duplicates enabled flag bits. When set this flag indicates that |
|
373 duplicate routing table entries are permitted. |
|
374 */ |
|
375 ESubTypeFlagEnableDuplicates = 0x00010000, |
|
376 |
|
377 /** |
|
378 The order descending flag bits. When set this flag indicates that |
|
379 routing table entries are to be arranged in descending rather than |
|
380 ascending order. |
|
381 */ |
|
382 ESubTypeFlagOrderDescending = 0x00020000, |
|
383 |
|
384 /** |
|
385 The routing sub-type parameter count mask. |
|
386 */ |
|
387 ESubTypeParamsMask = 0xFF000000, |
|
388 |
|
389 /** |
|
390 The zero parameter count code. |
|
391 */ |
|
392 ESubTypeParams0 = 0x00000000, |
|
393 |
|
394 /** |
|
395 The one parameter count code. |
|
396 */ |
|
397 ESubTypeParams1 = 0x01000000, |
|
398 |
|
399 /** |
|
400 The two parameter count code. |
|
401 */ |
|
402 ESubTypeParams2 = 0x02000000, |
|
403 |
|
404 /** |
|
405 The three parameter count code. |
|
406 */ |
|
407 ESubTypeParams3 = 0x03000000, |
|
408 |
|
409 /** |
|
410 The DevicePropCode operation parameter lookup routing sub-type. |
|
411 */ |
|
412 ESubTypeDevicePropCode = (0x00000000 | ESubTypeParams1 | ESubTypeFlagNone), |
|
413 |
|
414 /** |
|
415 The ObjectPropCode operation parameter lookup routing sub-type. |
|
416 */ |
|
417 ESubTypeObjectPropCode = (0x00000001 | ESubTypeParams1 | ESubTypeFlagEnableDuplicates), |
|
418 |
|
419 /** |
|
420 The OperationCode operation parameter lookup routing sub-type. |
|
421 */ |
|
422 ESubTypeOperationCode = (0x00000002 | ESubTypeParams1 | ESubTypeFlagEnableDuplicates), |
|
423 |
|
424 /** |
|
425 The StorageType operation parameter lookup routing sub-type. |
|
426 */ |
|
427 ESubTypeStorageType = (0x00000003 | ESubTypeParams1 | ESubTypeFlagEnableDuplicates), |
|
428 |
|
429 /** |
|
430 The FormatCode + FormatSubcode operation parameter lookup routing |
|
431 sub-type. |
|
432 */ |
|
433 ESubTypeFormatCodeFormatSubcode = (0x00000004 | ESubTypeParams2 | (ESubTypeFlagEnableDuplicates | ESubTypeFlagOrderDescending)), |
|
434 |
|
435 /** |
|
436 The FormatCode + OperationCode operation parameter lookup routing |
|
437 sub-type. |
|
438 */ |
|
439 ESubTypeFormatCodeOperationCode = (0x00000005 | ESubTypeParams2 | ESubTypeFlagEnableDuplicates), |
|
440 |
|
441 /** |
|
442 The StorageType + OperationCode operation parameter lookup routing |
|
443 sub-type. |
|
444 */ |
|
445 ESubTypeStorageTypeOperationCode = (0x00000006 | ESubTypeParams2 | ESubTypeFlagEnableDuplicates), |
|
446 |
|
447 /** |
|
448 The FormatCode + FormatSubcode + StorageType operation parameter |
|
449 lookup routing sub-type. |
|
450 */ |
|
451 ESubTypeFormatCodeFormatSubcodeStorageType = (0x00000007 | ESubTypeParams3 | ESubTypeFlagNone), |
|
452 |
|
453 /** |
|
454 The ServiceID operation parameter lookup routing sub-type. |
|
455 */ |
|
456 ESubTypeServiceIDOperationCode = (0x00000008 | ESubTypeParams1 | ESubTypeFlagNone), |
|
457 |
|
458 /** |
|
459 The device DP framework routing sub-type. |
|
460 */ |
|
461 ESubTypeDpDevice = (0x00000009 | ESubTypeParams0 | ESubTypeFlagNone), |
|
462 |
|
463 /** |
|
464 The proxy DP framework routing sub-type. |
|
465 */ |
|
466 ESubTypeDpProxy = (0x0000000A | ESubTypeParams0 | ESubTypeFlagNone), |
|
467 |
|
468 /** |
|
469 The object owner operation parameter decode routing sub-type. |
|
470 */ |
|
471 ESubTypeOwnerObject = (0x0000000B | ESubTypeParams0 | ESubTypeFlagNone), |
|
472 |
|
473 /** |
|
474 The storage owner operation parameter decode routing sub-type. |
|
475 */ |
|
476 ESubTypeOwnerStorage = (0x0000000C | ESubTypeParams0 | ESubTypeFlagNone), |
|
477 |
|
478 /** |
|
479 The default request registration routing sub-type. |
|
480 */ |
|
481 ESubTypeRequestRegistration = (0x0000000D | ESubTypeParams0 | ESubTypeFlagNone), |
|
482 |
|
483 }; |
|
484 |
|
485 /** |
|
486 Defines the routing parameter IDs. |
|
487 */ |
|
488 enum TRoutingParams |
|
489 { |
|
490 /** |
|
491 The first parameter. |
|
492 */ |
|
493 EParam1 = 0, |
|
494 |
|
495 /** |
|
496 The second parameter. |
|
497 */ |
|
498 EParam2 = 1 |
|
499 |
|
500 /** |
|
501 The third parameter. |
|
502 */, |
|
503 EParam3 = 2, |
|
504 }; |
|
505 |
|
506 /** |
|
507 Implements a simple single parameter map table entry which associates a |
|
508 single routing parameter value and target data provider identifier pair. |
|
509 */ |
|
510 class TMap |
|
511 { |
|
512 public: |
|
513 |
|
514 TMap(TUint aFrom); |
|
515 TMap(TUint aFrom, TUint aTo, TUint aSubType); |
|
516 |
|
517 public: |
|
518 |
|
519 /** |
|
520 The routing parameter. |
|
521 */ |
|
522 TUint iFrom; |
|
523 |
|
524 /** |
|
525 The routing table sub-type code. |
|
526 */ |
|
527 TUint iSubType; |
|
528 |
|
529 /** |
|
530 The routing target data provider identifier. |
|
531 */ |
|
532 TUint iTo; |
|
533 }; |
|
534 |
|
535 /** |
|
536 Implements a generic, multi-parameter routing table data structure. This |
|
537 table implements owns EITHER: |
|
538 |
|
539 1. A container of @see TMap node objects if implementing a single |
|
540 parameter table or the final level (n) of a multi-parameter table, |
|
541 OR; |
|
542 2. A container of @see CMap branch objects if implementing an |
|
543 intermediate level (1 .. n-1) of a multi-parameter table. |
|
544 */ |
|
545 class CMap : public CBase |
|
546 { |
|
547 public: |
|
548 |
|
549 static CMap* NewLC(TUint aSubType); |
|
550 ~CMap(); |
|
551 |
|
552 TUint From() const; |
|
553 void InitParamsL(RArray<TUint>& aFrom) const; |
|
554 void InsertL(const RArray<TUint>& aFrom, TUint aTo); |
|
555 void GetToL(const RArray<TUint>& aFrom, RArray<TUint>& aTo) const; |
|
556 TUint SubType() const; |
|
557 |
|
558 #ifdef __FLOG_ACTIVE |
|
559 void FLOGMapL(RArray<TUint>& aFrom) const; |
|
560 void FLOGMapEntryL(const RArray<TUint>& aFrom, TUint aTo) const; |
|
561 #endif |
|
562 |
|
563 private: |
|
564 |
|
565 static CMap* NewLC(TUint aFrom, TUint aSubType); |
|
566 CMap(TUint aFrom, TUint aSubType); |
|
567 void ConstructL(); |
|
568 |
|
569 TInt BranchFind(TUint aFrom) const; |
|
570 TUint BranchInsertL(TUint aFrom); |
|
571 TInt NodeFind(TUint aFrom) const; |
|
572 TInt NodeFind(const TMap& aNode) const; |
|
573 TUint NodeInsertL(const TMap& aMap); |
|
574 TUint Param(const RArray<TUint>& aFrom) const; |
|
575 TUint ParamIdx(const RArray<TUint>& aFrom) const; |
|
576 void SelectTargetAllL(const RArray<TUint>& aFrom, RArray<TUint>& aTo) const; |
|
577 void SelectTargetMatchingL(const RArray<TUint>& aFrom, RArray<TUint>& aTo) const; |
|
578 void SelectTargetSingleL(const RArray<TUint>& aFrom, RArray<TUint>& aTo) const; |
|
579 |
|
580 static TInt BranchOrderFromAscending(const CMap& aL, const CMap& aR); |
|
581 static TInt BranchOrderFromDescending(const CMap& aL, const CMap& aR); |
|
582 static TInt BranchOrderFromKeyAscending(const TUint* aL, const CMap& aR); |
|
583 static TInt BranchOrderFromKeyDescending(const TUint* aL, const CMap& aR); |
|
584 static TInt NodeOrderFromAscending(const TMap& aL, const TMap& aR); |
|
585 static TInt NodeOrderFromDescending(const TMap& aL, const TMap& aR); |
|
586 static TInt NodeOrderFromKeyAscending(const TUint* aL, const TMap& aR); |
|
587 static TInt NodeOrderFromKeyDescending(const TUint* aL, const TMap& aR); |
|
588 static TInt NodeOrderFromToAscending(const TMap& aL, const TMap& aR); |
|
589 static TInt NodeOrderFromToDescending(const TMap& aL, const TMap& aR); |
|
590 |
|
591 private: |
|
592 |
|
593 /** |
|
594 FLOGGER debug trace member variable. |
|
595 */ |
|
596 __FLOG_DECLARATION_MEMBER_MUTABLE; |
|
597 |
|
598 /** |
|
599 The routing parameter. |
|
600 */ |
|
601 TUint iFrom; |
|
602 |
|
603 /** |
|
604 The routing table sub-type code. |
|
605 */ |
|
606 TUint iSubType; |
|
607 |
|
608 /** |
|
609 The @see CMap branch object container. This container is only populated |
|
610 if implementing an intermediate level (1 .. n-1) of a multi-parameter |
|
611 table. |
|
612 */ |
|
613 RPointerArray<CMap> iToBranches; |
|
614 |
|
615 /** |
|
616 The @see TMap node object container. This container is only populated |
|
617 if implementing a single parameter table or the final level (n) of a |
|
618 multi-parameter table. |
|
619 */ |
|
620 RArray<TMap> iToNodes; |
|
621 }; |
|
622 |
|
623 private: |
|
624 |
|
625 CMTPParserRouter(); |
|
626 void ConstructL(); |
|
627 |
|
628 static void GetMapParameterIdsL(TUint aSubType, RArray<TUint>& aP1Codes, RArray<TUint>& aP2Codes, RArray<TUint>& aP3Codes); |
|
629 static void SelectTargetL(TUint aTarget, RArray<TUint>& aTargets); |
|
630 |
|
631 void Configure1ParameterMapL(TUint aSubType, const RArray<TUint>& aP1Codes); |
|
632 void Configure2ParameterMapL(TUint aSubType, const RArray<TUint>& aP1Codes, const RArray<TUint>& aP2Codes); |
|
633 void Configure3ParameterMapL(TUint aSubType, const RArray<TUint>& aP1Codes, const RArray<TUint>& aP2Codes, const RArray<TUint>& aP3Codes); |
|
634 void GetConfigParametersL(const CMTPDataProvider& aDp, const RArray<TUint>& aCodes, RArray<TUint>& aParams) const; |
|
635 void GetRoutingSubTypesL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
636 void GetRoutingSubTypesDeleteRequestL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
637 void GetRoutingSubTypesCopyMoveRequestL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
638 void GetRoutingSubTypesGetObjectPropListRequestL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
639 void GetRoutingSubTypesSendObjectPropListRequestL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
640 void GetRoutingSubTypesDeleteObjectPropListL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
641 void GetRoutingSubTypesGetFormatCapabilitiesL(RArray<TRoutingParameters>& aParams, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes) const; |
|
642 void ParseOperationRequestParameterL(TMTPTypeRequest::TElements aParam, TRoutingParameters::TParameterType aType, TRoutingParameters& aParams) const; |
|
643 void RouteOperationRequestNParametersL(TUint aRoutingSubType, const TRoutingParameters& aParams, RArray<TUint>& aTargets) const; |
|
644 void RouteOperationRequest0ParametersL(TUint aRoutingSubType, const TRoutingParameters& aParams, RArray<TUint>& aTargets) const; |
|
645 TUint RoutingTargetL(const TMTPTypeRequest& aRequest, CMTPConnection& aConnection) const; |
|
646 void SelectSubTypeRoutingL(TRoutingSubType aSubType, RArray<TUint>& aRoutingSubTypes, RArray<TUint>& aValidationSubTypes, RArray<TRoutingParameters>& aParams) const; |
|
647 void SelectSubTypeValidationL(TRoutingSubType aSubType, RArray<TUint>& aValidationSubTypes) const; |
|
648 void ValidateTargetsL(const TRoutingParameters& aParams, const RArray<TUint>& aValidationSubTypes, RArray<TUint>& aTargets) const; |
|
649 |
|
650 static TUint Flags(TUint aSubType); |
|
651 static TUint Index(TUint aSubType); |
|
652 static TUint Params(TUint aSubType); |
|
653 static TUint ParamsCount(TUint aSubType); |
|
654 static TUint SubType(TUint aIndex, TUint aFlags, TUint aParamsCount); |
|
655 |
|
656 #ifdef __FLOG_ACTIVE |
|
657 void FLOGMapsL() const; |
|
658 #endif |
|
659 |
|
660 private: // Owned |
|
661 |
|
662 /** |
|
663 FLOGGER debug trace member variable. |
|
664 */ |
|
665 __FLOG_DECLARATION_MEMBER_MUTABLE; |
|
666 |
|
667 /** |
|
668 The operation parameter routing sub-type map tables. |
|
669 */ |
|
670 RPointerArray<CMap> iMaps; |
|
671 |
|
672 /** |
|
673 The framework singletons. |
|
674 */ |
|
675 RMTPFramework iSingletons; |
|
676 }; |
|
677 |
|
678 #endif // CMTPPARSERROUTER_H |