[Gpephone-devel] Calendar Scheduling

[zze-Ost SEBASTIEN A ext RD-ILAB-PEK]

Hi,

In calical.h, we provide functions to create a particular type of calendar depending on the method (publish / request / reply / cancel), which requires the components that will appear in this calendar.
But we still provide something to add / remove components, and more important a set_method function but the method is supposed to be already set during the creation.

That's why I would rather have done it this way:

Create_ical() without specifyng the method
Add_components()
Ical_to_*method*_string() where *method* is one of publish / request / reply / cancel

What do you think?

Pink

-----Message d'origine-----
De : YANG Lin RD-ILAB-PEK 
Envoyé : lundi 26 mars 2007 17:11
À : zze-Ost SEBASTIEN A ext RD-ILAB-PEK; 'zhangli408 at gmail.com'; YU Yijun RD-ILAB-PEK
Cc : 'gpephone-devel at linuxtogo.org'
Objet : RE: [Gpephone-devel] Calendar Scheduling

 
Hi ,

Enclosed "calical.h" is the latest version of the header file for scheduling part.
With the interfaces provided by the header, I drawed the sequence diagrams in differrent scenario.
The header file provides a series of convenient shortcut functions to creat ical structure of differrent method. 
Advanced developers can also use the advanced functions in the header file to have more flexibility.

Expecting for your opinion!

Lin
>-----Original Message-----
>From: zze-Ost SEBASTIEN A ext RD-ILAB-PEK
>Sent: 2007年3月22日 11:32
>To: YANG Lin RD-ILAB-PEK; zhangli408 at gmail.com
>Cc: gpephone-devel at linuxtogo.org
>Subject: RE: [Gpephone-devel] Calendar Scheduling
>
>Hi,
>
> Here are the diagrams of the incoming and output process as they are 
>now and as suggested.
>
>I named the "publish" function string_for_{iTip Method} where {iTip 
>Method} is either publish, request or...
>
>I think this should work this way:
>cal_error_t cal_ical_string_for_{iTip Method}(iCal, output string, 
>output error_array)
>
>Cal_error_t could take 3 values meaning:
>- No error, the structure is valid for this method
>- Warning, the structure wasnot valid but could easiliy be changed into 
>something valid so we return you a modified output
>- error, the structure is not valid and cannot be easily changed into 
>something valid
>
>For the two last possibilities, the validation errors would be given in 
>the error_array, this avoids calling a check function afterwards and 
>repeating all the validation process.
>