jauto

Note: “Week 1″ means “status report after week #1″

While some happy students are already coding, I’m reading the docs. And it’s really good that I started with reading. The more I read, the more problems with JEP-0070 I discover (magic realm usage, unreadable transaction id in Digest schema). It seems that instead of implementing the JEP, I will have to fix it first.

In the meanwhile, I did some research and now I more-or-less know what-and-how I need to do in Apache part of my project.

Since much of decisions depend on what JEP-0070 is really going to say, and it takes some time to create The Right Solution, and I need to consult with other - smarter - people, who also need some time to think about it, I decided to leave this alone for now and do some coding in area which is unlikely to change (much): XMPP Client - a patch for Psi.

6AM. So you think I’m getting up so early to code? Wrong! I’m going to sleep at this hour! ;)

This was a nice week.

First of all, Jacek Konieczny became my mentor. At last I can easily talk with someone about my project (yes! he’s from Poland, just like me :)).

Second, as decided previousely, I did some coding this week, to “forget” about problems with The JEP. There are problems at HTTP side, so I did some coding on XMPP side :)

My Psi can - more or less - display incoming confirmation requests.

Moreover, they are sent by something that looks a bit like HTTP-Auth XMPP component. But at the same time, this something looks much like the example component from PyXMPP package ;)

Plans for next week

Set up nice website on SourceForge

I created project really long time ago, but: First, some people suggested that using SF (located in the USA) may be a problem when stating that no US activity was involved in my SoC development (yes, tax forms), so I was waiting for official statement about this. Then I was busy. Then I had time, but SF was down for maintaince ;) Etc, etc.

Talk with JEP authors to get their opinion and advice

I cannot run away from HTTP part forever ;)

Code a bit more

I’d like to release some code this week.

Study for my exams…

As you can see, I managed to set up something that looks like a project website

Other news: Psi patch is 90% done. As a side effect, I improved stanza error handling in Psi
Since error handling will be probably a bit modified before including in Psi mainline, I’d like to wait for the official version and then create my patch, so it can be easier applied. If, however, this takes much time, I’ll release a dev-version of the patch.

I also did some research on Apache modules for authentication.

And I’m in the middle of getting in touch with JEP-0070 original author to get his help.

Plans for next week

XMPP Component

let’s have some fun with Python!

preparing for exams at univ

why? oh why?…

Bad week, bad…
Bad in my personal life, but it was so hard, that it influenced my work and I didn’t do everything I planned, sadly. But fortunately all the bad is gone now, and I could grow stronger!

XMPP Component is.. hmm… 50% complete. I still need to add some request handling logic, but it should be fine really soon.

Plans for next week

Finish XMPP Component

More Python fun!

Prepare demo for mid-term evaluation

Next week, I need to show my progress to my mentor. Got to finish and polish unfinished things!

Exams at last!

Aaaaaaaa!!!!

As I announced on Psi-devel mailinglist:

As a side effect of my SoC project, I improved stanza error handling in Psi (or rather Iris).

I did much work in Stanza::Error class. First of all, now it has fromXml()/toXml() members, so you can easily create error element:

QDomElement e = createIQ(client()->doc(), "error", jid, id);
Error error(Stanza::Error::Auth, Stanza::Error::NotAuthorized);
e.appendChild(error.toXml(*client()->doc(),
client()->stream().baseNS()));

Secondly, I added error mappings based on JEP-0086. This means that now Psi can read both old and new style errors (including error text, so no more empty “Reason: ” message boxes).
To make it more funny, if there is no error text at all, you can get default error description from RFC.

Other thing: some of error message boxes in psi have formatted text (”<b>”, etc), but had “\n” newlines, which don’t work in formatted mode. I changed them to “<br>”.

You can pull these changes from Darcs repository located at http://machekku.uaznia.net/darcs/psi/
Patches:
1. Improved stanza errors handling in Iris
2. Fixed formatted error message boxes

BTW: While testing my changes, I found a bug in Disco dialog.
To reproduce: try browsing a new server (like jabber.org) using Agents protocol. In old Psi, you’d see error message. In new Psi, you don’t get any message.

When writing my SoC Application, I simply planned that first I’ll do the design, and then implement. However, problems with the JEP (which take some time to resolve, because I need to consult with the authors, who need to consult with someone, etc, etc) made it impossible (I cannot do the design if requirements are still to be determined). So I had to change my strategy.

After doing something that seemed to be more-or-less chaotic, I noticed recently that this really is Incremental development.

It’s not so hard to notice that my project is really a set of several smaller projects. I did initial draft design while writing my application. It has no details, of course.
And now, I simply take each of components, one after another, and do small desing + implement cycle. Moreover, implementation/testing phase of one component usually overlaps with research/design of next one. Why? Maybe I like jumping between different things.

I started with Psi patch: I was already familiar with Psi source code and the task I needed to accomplish in Psi, so research and design were really quick. And I started coding. In the meanwhile, I installed PyXMPP (for XMPP Component) and went through component examples.
Now, while working on the XMPP Component, I’m already checking Apache docs.

And that’s the way I work

Yaaaaaaaay! Exam passed! Happy happy!

Now, more on-topic news:

Work on XMPP Component is going really well. Yes, it is still unfinished, but… If you check my old schedule, there was one week planned for XMPP Component and one week for integrating XMPP Component with Apache module. Honestly, now it looks like XMPP Component will be a something like a server for confirmation requests, and Apache module will be a simple client (you can do authentication in Apache by checking user passwords in a file: this will be the same, but I’ll be “checking in” XMPP Component). So right now I have to put more efford into finishing the Component, and then Apache module will be really quick and easy.

While testing XMPP Component together with my modified Psi, I found a really annoying bug in my psi patch. And it took me all evening to find it. Hmm… Handling of element namespaces in Psi is really tricky… and honestly I’m still not sure what is going on there… but at least I found out how to fix my problem.

Plans for next week

Two main points:

• Submit Psi patch
• Release XMPP Component

Someone could say that I’m getting behind the schedule. The truth is that I’m dynamically changing the schedule, because I have to. I’m taking days from last weeks of the old schedule, from “documenting and packaging” time slot. Why? I noticed that it’s not a good idea to wait to the very end with releasing everything. Especially with Psi patch. Why? Because Psi is changing so much now, that even waiting few days makes it hard to merge my patch with the mainline. So I need to finish documenting the code in my patch now (as required to submit a patch to Psi) and try to get this into mainline ASAP. If I don’t spend a day or two on this now, I’ll have to waste all week at the end of August rewriting the patch to work with latest mainline.

Other plans:

• Jabber SoC Conference on Tuesday
• Mid-term meeting with my mentor on Thursday
• Start Apache module (if time permits)

While planning this project, I thought that it would be a waste to limit myself just to HTTP requests with HTTP Authentication. Just think how many of the sites you visit every day uses HTTP Authentication? And how many displays small user/password form and maintains everything in PHP sessions, etc? So I thought it would be nice to have a PHP function triggering all the XMPP-part if the protocol, without employing the HTTP Authentication headers.
Or why not to use it with your 3-python-line long HTTP server which you use to share files with friends?
Or something else?

And so, partially to make the above come true, and partially to make my testing job easier, I created a simple Python function + command line utility that triggers confirmation request and gives back the result.

jauto daemon 0.1 with command line request tool is coming later this week! First I need to kill some stupid bugs, I don’t want you to laugh too much while looking at my code