I hope this report is not too late.
In the last 3 months, I implemented XEP-0136 for Prosody. This experience is really awesome: great mentor(Matthew Wild), active communities(Prosody, Gajim) and the wonderful organization(XSF), they've helped me a lot on this project. Many thanks to them! And, thanks to Google, who makes all of these possible, :)
What have been done
XEP-0136 is almost completely implemented:
Not perfect, but workable.
The 3rd part of XEP-0136, Off The Record, is too complicated, and not practical I think. So MattJ and I decided not to implement this feature, and implement another "XEP" instead -- XEP-xxxx: Message Archive Management, which is a much simpler version of XEP-0136.
What to be done
I'll continue maintaining mod_archive and mod_archive_muc. There are still some little issues, and I'll fix them in the future.
All the code is available at prosody-modules. Any suggestions are welcome. :) Please report issues here, or contact me at shinysky1986 (A T) gmail dot com.
GSoC 2010
Server Side Message Archiving For Prosody
Tuesday, August 24, 2010
Monday, August 09, 2010
Week #11: mod_archive_muc
This week I implemented a new module: mod_archive_muc, a simple version of mod_archive, which is the implementation of XEP-0136.
In mod_archive_muc, we simply archive every message regardless of the collection. And retrieve them later with any combination of three filtering attributes - 'with', 'start' and 'end'. This is much simpler than mod_archive.
The Next Step:
* Go on finalizing the code.
* Do testings.
* Prepare for the final evaluation.
In mod_archive_muc, we simply archive every message regardless of the collection. And retrieve them later with any combination of three filtering attributes - 'with', 'start' and 'end'. This is much simpler than mod_archive.
The Next Step:
* Go on finalizing the code.
* Do testings.
* Prepare for the final evaluation.
Wednesday, August 04, 2010
Week #10: Efficiency Improvement
Last week, I mainly focused on efficiency improvement, testing and bug fixing. Up to now, most of them are finished.
Improvements and Bug-fixing:
* Keep collections stored in REVERSE chronological order.
* Make sure result set are in chronological order(as specified in XEP-0136).
* Use binary search to improve collection inserting speed.
* Use util.jid.compare to do JID matching.
* Fix a bug about time stamp.
* Some other minor fixes.
The Next Step:
* Go on finalizing the code.
* Do some testings.
Improvements and Bug-fixing:
* Keep collections stored in REVERSE chronological order.
* Make sure result set are in chronological order(as specified in XEP-0136).
* Use binary search to improve collection inserting speed.
* Use util.jid.compare to do JID matching.
* Fix a bug about time stamp.
* Some other minor fixes.
The Next Step:
* Go on finalizing the code.
* Do some testings.
Tuesday, July 27, 2010
Week #9: Preferences Interpretation
This week I mainly finished these features:
* Interpreting preferences when performing automatic archiving, to determine whether archive the given message.
* Mapping an message to some collection based on timestamp, to determine which collection the give message should be archived into.
The next step:
* Keeping archived collections in chronological order.
* Making sure result sets returned to clients are sorted in chronological order.
* Interpreting preferences when performing automatic archiving, to determine whether archive the given message.
* Mapping an message to some collection based on timestamp, to determine which collection the give message should be archived into.
The next step:
* Keeping archived collections in chronological order.
* Making sure result sets returned to clients are sorted in chronological order.
Monday, July 19, 2010
Week #8: Replication
This week I implemented 'Replication'.
So the most part of this project has been finished. Yeah~
But, there are still a lot of TODO-es remain.
So in the next several weeks, I'll fix these problems.
Next step:
* Parsing preferences to determing whether archive the incoming messages or not.
* Mapping an message to some collection based on timestamp(?)
So the most part of this project has been finished. Yeah~
But, there are still a lot of TODO-es remain.
So in the next several weeks, I'll fix these problems.
Next step:
* Parsing preferences to determing whether archive the incoming messages or not.
* Mapping an message to some collection based on timestamp(?)
Tuesday, July 13, 2010
Week #7: Archive Management - Part II
This week I finished the implementation of "Archive Management", including:
Actually, I've finished it on July 7. After that, I was always thinking about how to implement "Replication". This part(Replication) seems like implementing a "version control system"(Simpler, of course). I still can't figure out an efficient way to do this, so I decide to make it "workable" first.
Here is my thoughts:
The next step:
- Retrieving a list of collections
- Retrieving a collection
- Removing a collection
Actually, I've finished it on July 7. After that, I was always thinking about how to implement "Replication". This part(Replication) seems like implementing a "version control system"(Simpler, of course). I still can't figure out an efficient way to do this, so I decide to make it "workable" first.
Here is my thoughts:
- Add a "access" attribute to chat element, representing the time this collection is last accessed(created/modified/removed).
- modified_handler check this "access" attribute to determine if include this collection in the result set or not.
- If a collection has no any child, that means it has been deleted.
The next step:
- Mid-term Evaluation, :)
- Replication
Monday, July 05, 2010
Week #6: Archive Management - Part I
This week and the next week(before the mid-term evaluation), I planned to implement these features:
* Retrieving a List of Collections
* Retrieving a Collection
* Removing a Collection
Actually, these features involve implementing XEP-0059: Result Set Management. So this part would take more time.
After this, I'll implement Replication.
* Retrieving a List of Collections
* Retrieving a Collection
* Removing a Collection
Actually, these features involve implementing XEP-0059: Result Set Management. So this part would take more time.
After this, I'll implement Replication.
Subscribe to:
Posts (Atom)