You might have faced to download gigabytes of repositories with Hg. In my case, a big portion of Mozilla repositories depends on it and wanted to download that huge repos from the university network. University bandwidths are mostly underused 😉
Hg uses hgrc file to load configurations. (Per repository) You can go to your repository, .hg/hgrc and add following with your configurations.
host = your.proxy.host:8000
passwd = password
user = username
In case you are using hg from a preloaded instance to clone repositories to another location, you can simply add your configurations as a prefix to your command.
hg --config http_proxy.host=[proxy_ip]:[proxy_port] --config http_proxy.user=[username] --config http_proxy.passwd=[password] push
Make sure if you have special characters(@,%,,.) in your username or password you use the suitable character representation for it. ie : use %40 instead of @ symbol. This will also help in finding special character representation.
That was a great period to remember for a life time. Reading, Coding, again reading, refactoring, some annoying issues (things get really annoyed when you update the local repository during a bustage 😉 but still there was a lot of things to learn), getting reviews from experts..!!
I really enjoyed the SoC and hoping to continue contributing to internet giant Mozilla. There are few knits I still have to fix on patches and will be working on them in future as well. I got to know that fake server was something important to calendar so I will be focusing more into it and then fixing other proposed issues which were left behind due to sudden intrusion of the fake server.
Variations from the proposed deliverables as I decided with Mohit:
- Week 3: Patch for schedule-calendar-transp
Dropped since it requires some UI related changes
- Week 4 – Week 6: Patch for If-Schedule-Tag and If-Schedule-Tag-Match
Patch is done, needs to be made reviewable & handle edge cases
- Week 6- Week 7: Patch for schedule-default-calendar-url
No need to implement in lightning since this is more of a property that will allow clients to manage calendar collections for one user. More suited to a dedicated client for a particular server.
- Week 7- Week 8: Patch for min/max date-time
That is something related to the server, and is not returned in a PROPFIND request.
- Week 8- Week 9: Patch for max-attendees per instance
UI Changes required
- Week 10 – Week 12: Unit tests for schedule-tag
On track, this evolved into a major chunk of the project, with the fake server implementation and its design to support overriding, a rough working patch is completed, a more robust implementation in the works.
- Week 12- Week 14: Mozmill tests for invitation scenarios
This has been completed. Just some minor cleanup required with the packaged test thing.
- Week 14- Week 15: Patch for schedule-force-send
Needs UI change became less of a priority.
On the way, fake server became something that took a long time since it was a RFC implementation rather than a modification.
Throughout the GSoC period I received a great mentoring from Mohit, so herewith I’d like to give my gratitude to him for all the time he allocated and being cool throughout the period. Also, to Philipp for all the tech reviews. Without them I’d never caught up the complex things in the codebase.
Fun Facts :
Well, If you are going to contribute to Mozilla TB or Lightning by any chance lol, you should probably know these two abbreviations. You can’t find them in Google anyway.
m-c and c-c : I drove into trouble several times by hearing to update m-c and c-c. I was thinking that is something related to changset headers and hashes. well at last got to know, they weren’t. Those were the two folders named “mozilla-central” and “comm-central” in the repository.
PS: I searched in google for the term “c-c and m-c revisioning” and got the result “Women’s Choices Within Market Constraints: Re-Visioning” 😉
I will update the blog with my future works related to Lightning as well.
The error raised in the PROPFIND block could fixed with the help of Philipp. It was due to wrong sequence of initialization messages to the calendar. To initialize a CalDav calendar properly, a sequence of asynchronous messages need to be sent.
- Initial PROPFIND response
- OPTIONS response
- PROPFIND response for user address set
- PUT request and response
- REPORT response
After properly sending messages, the calendar could initialized with items. Added responses and configurations in js objects, so server configurations can be changed easily.
github link for the test :
After the initialization of the calendar properly, I’m moving on with adding schedule-tag and if-schedule-tag-match test cases to the code.
Schedule-tag changes are evaluated on 2 scenarios.
- Changes to Organizer’s object resource
- Changes to Attendee’s object resource
For organizer’s changes, schedule-tag may or may not be changed on the type of the change.
- If the organizer changes the ical object with a PUT request, schedule-tag of the organizer’s object should be changed and changes should be merged with attendee objects.
- Schedule tag will not be changed as a result of processing an attendee PARTSTAT change response.
For attendee object resources there are three cases affect to the schedule tag.
- Schedule-tag should be changed after processing updates from the organizer which contains updates more than other attendees’ PARTSTAT changes.
- Schedule-tag should not be changed after processing updates from organizer which only contains PARTSTAT changes of other attendees.
- Schedule-tag should be changed after processing HTTP requests like PUT,COPY,MOVE from the attendee himself.
It took me sometime to understand the scenario from the server perspective. I’m not sure is it jumping into a prejudgement by understanding that, according to 2nd case about attendee’s schedule-tag change, server leaves attendees outdated by not letting clients updated after processing changes from other attendees.
On the implementation, I’m implementing the organizer scenario first with changes to the object resource. Implementation goes like following.
- change the existing calendar item(date/time, summary)
- send the changed item to the calendar by cal.modifyItem(Item,oldItem,listener)
- merge the change with attendee object resource and update the schedule-tag after PUT request
- reply to the multistatus message with new schedule-tag
- assert client’s item and servers item to make sure both are similar
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.