Dear list, I have written down some ideas I have about a few GSoC projects here. I'd love nothing more than you reviewing them before I fill out the GSoC form! (warning: this gets really long (& ranty):D)
1. Chat Interfaces: Most of this project is done in 1.0.x already, AIM is already finished. So I thought of writing a libpurple plugin and a telepathy plugin too... These would let StatusNet connect to many number of protocols without doing the protocol compliance heavy lifting... Besides new protocols are often ported as purple plugins which can be used right out of the box! Both purple and telepathy extensively support DBus, there's a PHP-DBus binding in PECL (http://svn.php.net/viewvc/pecl/dbus/trunk/examples/) being developed by one of the PHP core developers, its been under development for quite some time but doesnt have a release, but is quite stable. I have contacted him and he's "put a release on his TODO list". About scalability: DBus is built to be compact and fast, and Meebo uses libpurple, guessing by the amount of traffic they handle (millions of users), it should be pretty scalable! I am very very excited about telepathy support. It's the "Open Standards" way! Don't know about scalability details though. Deliverables: 1st Phase: 1. Standalone IRC, MSN, Y!IM plugins [use external libraries. I searched and there isn't one for Yahoo.] 2. Code to format notices for delivery over a good number of protocols 3. A libpurple DBus api library with all functions required by an ImManager 4. Purple plugin for bidirectional updates. 5. UI for setting up accounts (a config option for setting maximum IM accounts per user and per protocol) 2nd Phase (supposed to be hard since there are many things to take care of): 1. A Telepathy Client API (all functions required by an ImManager) 2. A Telepathy Client Plugin This would implement most of the things described here http://ur1.ca/t1ul If time remains (or even if it doesn't): 1. Telepathy protocol implementation. i.e implement statusnet as a telepathy protocol, this would allow awesome tubes (http://telepathy.freedesktop.org/wiki/Tubes) to be set up between applications for sharing statuses. [I still wonder how that could be used] (I doubt there will be any more time) 2. Implement tracking in IM updates. This project is the project I'm moost excited about, but I am concerned about the timeframe. (Should I reorder the deliverables?) 2. Real-time search & Twitter Stream API: I think these two projects are largely related and can be accomplished parallelly (Presenting the data in HTML, XML & JSON is very much secondary to getting the logic correct), cracking how to implement one of these is the key to the other. It is a pity that Sphinx is optimised for reading and not for writing, making real-time indexing an expensive process. But there is this weird idea of a delta index http://sphinxsearch.com/docs/current.html#live-updates wherein you have a smaller real-time updated index and a large main index which is less frequently updated. When searching, the smaller one is searched first and then the bigger one. This can be used to load search results that are up-to-date to the second of search request, then the real real-time part can be implemented as follows - Write a daemon which sets a unique ID to each search request when it is received, then appends the keywords to an inverted index file. - When a notice is posted, after being checked for conditions like is_local etc. it is sent to this daemon, which then matches its conents against the inverted index file, the daemon then sends any matches to a plugin hook say, RealtimeSeachHit. - A RealtimePlugin class then implements transport to browser (in onRealtimeSearchHit) to the search requestee with the given unique ID. It also notifies the daemon when a search window has been closed/disconnected the daemon then removes the keywords from the index file. - Another RealtimePlugin class can be similarly written to expose the stream api using meteor (note that pure Bayeux Protocol implementations cannot do this, so something like tornado or Jetty://). - The API requires a handful of methods to be implemented, So it will require the daemon to have these built in. (Note: the daemon above would be implemented in the same plugin, sucking on HandleQueuedNotice or a similar hook) 3. Twitter Lists! This is one of the easy ones! I happen to know much about notice handling and caching from my work on the gallery plugin. Here goes an implementation plan: - Use peopletags, add the inbox delivery logic to whoGets() mark the source as NOTICE_INBOX_PEOPLETAG. - Write a widget for the sidebar in profile pages (showstream) showing most recently updated peopletags for that user. - Allow subscription to tags (new peopletag_subscription table) - Implement OStatus for each /user/all/peopletag resource (I have yet to find out how to do this, guessing it will be easy) - Allow ajaxy remote subscription through a form in the widget. - Show the most subscribed lists in the Public Timeline sidebar. - Take care of caching. (1 cache per-list, cache is blown ("key;last" isn't) when a new notice arrives) - API! (That is going to be clever copy paste. :D) 4. People Search server I think this idea is the most intriguing of all, mainly because I know little about search engines. I think ideally, it would use Sphinx and a weightage system similar in algorithm to @cvollick's Karma plugin to rank people. Also will it be good to aggregate just hCards without OStatus? something like http://sig.ma does? (I think no) -- I am absolutely torn between these projects, and, I want to make sure I get to participate, obviously ;). So, do you think it would be right to apply to more than one project and see which one gets through once the mentors have ranked the applications? I asked #gsoc IRC channel and they said it shouldn't be an issue (GSoC allows a maximum of 20 applications from one applicant. SN is the only project I'll be applying to, so 4 projects)... Sorry for not having done Mock-ups and prototypes, I so wish that I could have. It is that time of the year when I have to have to concentrate on studies (I have no choice). I will, hopefully be free (and with OK exam results) in May when there will be a lot of time before the actual coding starts. Thanks a lot for reading! No, really, thanks a billion! :-) -- Shashi OStatus: identi.ca/g0 _______________________________________________ StatusNet-dev mailing list StatusNet-dev@lists.status.net http://lists.status.net/mailman/listinfo/statusnet-dev
