I'm back, again.

At last, it seems the undersea cable is repaired already, since I can again access my blog pages after more or less a month's time.

I've ever said to keep updating this blog daily, but again, for some reasons, I failed on it. But, if time permits, I'll start again, just like the Matrix reload.

During the two months passed by, a LOT of interesting things happened, but I can't record them all in time. I plan to recover them as much as I can from my memory, 'cause to memorize the interesting things is something more interesting.

Have fun.

The agreement on RTSP & the future...

It seems in Windows media player 11 no more mms protocol is supported, though the request for a stream like mms://foo.com/bar.asf will still work, but it works as a protocol rollover URL, see more about rollover on MSDN.

So, when it comes to request a stream for dedicate stream server, the best choice is RTSP, while is a open standard, other streaming protocol like Real and QuickTime from Apple also build their streaming service on it. It then seems appealing for us to concentrate on it to deliver better stream over P2P with the support of RTSP.

I'm still wondering whether it's feasible to realize the interaction through P2P-based streaming service, maybe it'll help to give some clue, but the clear picture I still cannot see, more works need to be done before the real things get to work.

Big map on MMS streaming over HTTP

Many thanks to SDP team, their HTTP streaming protocol version 1.0 finally gives me the clear idea on how the handshake takes place between Windows Media Server and the client. The handshake contains two phases instead one, which I mistaken for a long time, and the wrong idea made my code work weird and I tried all means to find out the reason, and because of the lack of the big map on MMS streaming over HTTP, I did a lot of work in vain. That's the pay for exploring the unknown.

Ok, let me introduce the big map to all you guys, though you can get the detail easily from SDP's document, I think the simple words below can give you some ease.

Client: request ASF header in html form

Server: reply with ASF header only, then disconnect from client

Client: parse the ASF header, then re-connect to the server, and send the re-request

Server: reply with ASF header again, followed by media packet

That's it, that simple.

Who's responsible for libjingle updating now?

From Google's page, I'm redirected to the repository on sourceforge, where I find the updated version 0.3.0, which dated on March 16, 2006.

That's all right for me at the time, but when I want to search some more detail on it, I googles it with CodeSearch, what a surprise, I get the result telling me, I can get a newer version 0.3.9 from a Gentoo's net-dist directory! What's more, I then googled more with the keywords: "libjingle gentoo", then, I see version 0.3.10, huh, now I just wonder where can I find the latest release of libjingle, just wonder, no other consideration related. How can a famous open source project act in such a mess? Just my complaining.

By the way, I haven't read the code in gentoo's directory yet, maybe that's not the whole thing I'm complaining about, just version number changes.

And PS again, from the discussion on Google Groups, I'm pointed to another project on Sourceforge Tapioca, where I get the version 0.3.10, hmm, that's more interesting now.

Information update: the version 0.3.10 from Tapioca mentioned above is maintained by the Tapioca team, so the version number has little relation with the official one, and from the ChangeLog, you can see that, actually, there's no significant change made from the official version, just some modifications which is needed for their project.

I don't know where I'm going, but I'm on my way

Somewhat lost these days, all day long's coding without progressing makes me tired and confused. I know I'm on the way to finish the project, but what about my ideas about P2P in the old days? Am I lost the passion on it? Or just some disappointing feeling surround me for a while? I have no idea which place these days work leads me to, I need some guidance, or just take a break and have some review of my thinking?

Yep, I need a short term goal, and I need someone with me to work around it. Let me have a list here:

A platform for:

a. nowadays popular P2P file sharing protocol, in order to learn the actual behavior of them

b. well known P2P lookup protocol, either unstructured or structured, to do some experiment on it, and get a benchmark

c. better simulation on protocol

d. from the data comparison, conclude a brand new/hybrid protocol for P2P network use

e. empower the P2P network with efficient resource location mechanism, with the help of our lab's great ability on web searching & data mining

An application built on the platform:

a. show the ability of P2P and make it legal

b. flexible with the underlying platform changes

c. great user experience, trying to plant the decentralization into people's mind

A demonstration of my ability on research:

Paper is required

Nothing is easy, but all the things are based on the experiment data, so, the runnable platform is on the first priority.

Coding peacefully, but the communication during this period is critical for the whole plan.

Codeplay

Decoupling legacy code

Nearly one week's rumination on how to loose the coupling of the design, I have got a deeper understanding on how to write elegant code. Often I'd like to mention loose couple in design, but what on earth in practice, I *DO* the worst thing I can even expect. Still, I've got not enough experience on how to do the right coding thing.

But the good thing is, here is the chance for me to enrich myself on the weakness mentioned above. How to define the relationship between each module, and how to organize the communication among them, I need a rendezvous in the project to route all the messages among all function modules, maybe some great ideas can be bought from SOA? Just like the ESB? I decide to call this module the core, and the former core I define now seems some basic supporting utilities and system call adapters. All the former core things can now be designed in a pure library way, and so do the upper concrete protocol implementation, they all communicate with each other through the right now core, and the final application built on my project just only see the protocol modules at all. And to make each module ( including the lower system adapter and the upper protocol modules ) pluggable, the core should be designed as flexible as possible, and the dynamic plugin mechanism should be deeply considered to achieve the goal. All the couplings are just with core and nothing else, that is what I need.