Mid term evaluation results were posted on yesterday by Google and I have passed! Cheers! 🙂
Last week was kind of a milestone of fakeserver test journey. I could establish the communication between the calendar and the test successfully and transmit upto multiget request between the calendar and the test.
The test up-to now.
Currently the test has 2 path handlers.
Sequence of messages flow between the test and the calendar.
- Test sends addItem() message with PUT method to the calendar.
- Calendar sends back a multiget message to retrieve calendar data with REPORT method.
- Test serves the multiget request with Schedule-tag and, etag, href address and the actual calendar data. (Now, this is where I currently stopped. multigetRequestHandler’s SAXparser throws a fatal error at the response which is believed to be due to an error with wellformness of the response.)
Here onwards things have to be dealt with cautious. After move onto add the item successfully to the calendar, operations which the schedule-tag involved in have to be implemented. For that, schedule-tag needs to be calculated according to the RFC standards. Already created the method for schedule-tag manipulation, but definitely needs more situations handled when things move on.
I use wireshark to capture the packets which are being transferred between two endpoints. This is a screen shot of the first win. 🙂
Another todo : Needs to move handler functions to separate .sjs files for more clarity. But at the moment I thought to move on leaving them in the test file.
It has some serious operations! Since the server needs to provide functionality to Create/Modify/Delete operations on requests, the logic behind the RFC standard operations needs to be embedded in the server backend.
During the test, server is created on localhost:50001 (I used the particular port, so it is easy to trace packets when comes to debugging) and requests are sent to specific URIs.
ie: create operation may send a request to <BASE_URL>/create/event.ics with PUT header. Also, If-None-Match : * header specified. We assume there are no conflicts with other files and etags are manipulated perfectly. Since the server is not a real file container, instead of creating temp files at the runtime (for new resources) and bind to the URL, an ics file will be registered to a URL and will be served by <BASE_URL>/create/event.ics url.
Once the file is asserted existing, the server will return 201 status code, etag and the schedule-tag. Calendar needs to keep them stored.
I spent the last week getting familiar with httpd.js, NSIHTTP* api and other test, util modules. I could create the basic handler functions and listeners needed to manipulate requests/responses. I found using wireshark to capture packets travel between two parties very helpful to move forward with the test.
My next target is to handle various requests on various URLs and treat them accordingly.
It is time for testing. We decided that the test needs to be a unit test which can more generally surpress calendar operations, with sequence of message injections.
That way we can make sure calendar operations are taking place according to RFCs and reacts to predefined behaviour according to given responses. XPCshell based unit test will provide preloaded response data imitating various CalDav server behaviours.
Unit test will basically create a temporary HTTP server on localhost using httpd.js. Calendar will send sync requests to the server and server will respond to them with different response data. Calendar reactions will be asserted against expected values.
As we decided, the test needs to be modular enough to mimic behaviour of different CalDav servers and changing the response data easily. The most challenging thing would be bringing the modularity to the test.
The test will contain :
- Send initial PROPFIND request
- Send multistatus requestto get hrefs of events
- Send multiget request
- Inject calendar data
- Assert for schedule-tag and etag values
It was another patch for schedule-tag with support to If-Schedule-Tag-Match property. I made Schedule-Tag property implementation more pluggable, so it makes the isScheduleTagSupport attribute true at startElement() of SAX parsing if the server returns Schedule-Tag value and then proceed.
To support If-Schedule-Tag-Match, it was needed to change the If-Match request headers in DELETE, MODIFY operations in to If-Schedule-Tag-Match. But possibly still some servers don’t support processing Schedule-Tag. Therefore I added lines to check if the response contains the schedule-tag before setting the request header. If not, it continues with the usual Etag comparison.
If the schedule-tag value belongs to the response is in the mItemInfoCache, there is no possibility that the server not support the header.
Still a lot of testing has to be done on the implementation, though it looks simple, it involves in all critical operations.
I hope to work on adding few more functionalities to the mozmill test for the imip-bar and more testing on schedule-tag implementation on next couple of days.