This project is read-only.

Architecture / Plan

Oct 15, 2009 at 12:07 AM

I have been reading through the discussions and there doesnt seem to be much of a plan...yet. I think for a project to be taken seriously we need a plan.

So to start this off i have identified some various units of work(based on discussions i have seen & read).

  1. XMPP/Wave Client API (WCF?)
  2. XMPP/Wave Server (WCF?) (Includeds Federation API)
  3. Wave Robots API
  4. Demo Silverlight/WPF Client

These of course need to be expanded on, but this can be done once we have a basic architecture. But i dont know what people have already done towards this project.

Oct 16, 2009 at 10:38 AM

I think that at first we need to identify very clear on what it is that's going to be built because the project description isn't very clear on this. I can think of several different components to this system.

  • A public client/server API for Wave in C#
    • The Wave client/server model
    • Federation protocol
    • Robots API
  • A server implementation with the afore mentioned API
  • A client implementation with the afore mentioned API

I think questions like the following should be answered first;

  • Are we going to built a public API?
  • Are we going to built a server implementation?
  • Are we going to built a demo (or perhaps full fledged) client?

Once these area's have been identified one could argue that each of those can form some kind of 'team' or 'feature crew' which is responsible for implementing those.

I'm really curious on what your view is on this, so please get the discussion going with other alternatives!

Oct 16, 2009 at 10:56 AM
AthemeX wrote:
  • Are we going to built a public API?
  • Are we going to built a server implementation?
  • Are we going to built a demo (or perhaps full fledged) client?

A public API would be the right way, I think, both a client and a server one.

I think implementing a server (and client) along side would be possible, and a great way to make sure the API is solid enough.

Oct 16, 2009 at 3:58 PM

I second these postings.

A public API would definitely open a wide range of potential avenues for development. I followed another post from lloyd regarding extending WCF to be used as transport channels that are XMPP compliant. His recommendation at the top seems to be right on target. Along with the questions asked by AthemeX, I recommend a full fledged client in once again supporting Ask's answer to server/client simultaneous.

I will volunteer to assist on the client side of things whether that be client or API.


Oct 16, 2009 at 4:10 PM

I also found a project in google code from a guy who started a robot api in .net. ill invite him over here.


Oct 16, 2009 at 5:27 PM

I think we need an decision on using WCF or not. This is quite a major one, that once chosen is going to be hard to change.

The biggest problem with WCF is portability to Mono, but they should catchup and have it fully supported soon

My position is that we should use WCF as the basis for the API's & the Protocals. The hardest part (in my opinion) is building the XMPP & HTTPS Transport & Channel which i have no idea how to do (but is possible as there is a commerical componet that does it) but am very interested in learning how to do.

What are other peoples positions/opinions?

Oct 16, 2009 at 5:36 PM

With olive underway, WCF should soon be ported for mono right? Even if this isnt implemented yet, what are the restrictions of not having it available?


Oct 16, 2009 at 6:14 PM

I believe they have a partial implementation which might be enough

Oct 16, 2009 at 10:46 PM

Another question one might ask is how important is interop with mono? I think personally that the first priority should be a 'native' or 'pure' .NET implementation, as this will give you the full power of the .NET framework and components itself. How important do you guys think the interop with mono is?

Oct 16, 2009 at 10:54 PM

As far as I'm concerned WCF is the only way to go, it is by far the most advanced networking api in the .net framework with the most extensibility points. WCF is very customizable and I don't think it should be very hard to implement an XMPP protocol on the WCF stack.

If I understand the wave documentation fully, they use a basic XMPP protocol (which there are existing .NET libraries for available) and they (google) have created some extensions and additions to this protocol. So perhaps it's even possible to use an existing XMPP implementation for .NET to get up to speed? I personally don't have any experience with any of these libraries but perhaps somebody else can answer that?

Oct 17, 2009 at 12:13 AM

If we can find a Third Party (Open Source) library for XMPP in WCF then we should use that as a basis and build the wave extensions on top of that.

(Depending on the Library might be worth to Fork???)

Im currently looking into how one might implement a XMPP WCF Channel seems to be a good sample one here

But i cannot find one already implemented. And from their wikipedia list no .Net Servers and only 3 .Net Apis (one is dead)

Also i just got my Invite to Google Wave, so if anyone wants to talk, add me

Im of the opinion that if mono isnt upto scratch yet, then we should ignore it, and wait until such point that it is.

If i get a chance between work over the weekend i will take a quick shot at implementing a XMPP WCF Channel, its only a 70 page?? RFC

Oct 17, 2009 at 8:21 AM
Edited Oct 17, 2009 at 8:22 AM

We definately should go with WCF and worry about mono compatibility later.

Oct 17, 2009 at 11:34 AM
lloydsparkes wrote:

Im currently looking into how one might implement a XMPP WCF Channel seems to be a good sample one here


I was looking around on MSDN and there's a lot of info there on how to extend WCF with custom channels. You can also have a look there:

Oct 17, 2009 at 1:46 PM

I agree. WCF is definitely the .NET way :-)
And as lloydsparkes mentions, if we can find a decent open source XMPP library we can use, we should go with that.

Interop should not be an issue. As I see it, there's no reason to use any COM components, what so ever.

Also, I still haven't received a Wave invite. Does anyone have an extra to spare?

Oct 17, 2009 at 6:52 PM

Thanks will start reading it :D


Oct 17, 2009 at 9:05 PM
Edited Oct 17, 2009 at 9:07 PM

This one doesn't use WCF, but I heard it's pretty good and is mono compatible.


However, I do think using WCF is the way to go because it's much simpler and flexible.

Oct 18, 2009 at 5:28 PM

Lloydsparkes, did you manage to make any progress on implementing the XMPP protocol on WCF? or is there anything I might be able to help you with? Let me know!

Oct 18, 2009 at 7:13 PM

I started reading about it last night, and will be starting some sort of implementation this evening (i work all weekend), Once i know the details im sure i will be asking for help :)

Oct 18, 2009 at 10:00 PM

Ok i have been quickly reading all the documentation, and i think i have created all the Code to make this extension usable

You can take a look here 

Now this is the first time i have ever done anything like this, so theres a good chance i have done it completly wrong.

Most of what i have done, is standard code that you need for a custom Channel.

I now think that all I (we) need to do is to actually write the main channel which should be a process of doing the following.

converting the xml stream as it comes in to XML Documents so that it can be passed to higher WCF components and made into contracts / services.

converting messages from higher up in WCF from XML documents to something that can be put into the XML stream.

It also needs to be able to setup the connections correctly. For now i am ignoring the TLS/SSL/SASL requirement, but this should be fairly easy to add in after we have the basic XMPP channel tested and working.

I'm still reading the documentation & examples to work out the best way of doing the above.

All feedback & critisms are welcomed, as this is a totally new area to me, and am looking to learn lots

Oct 19, 2009 at 11:17 PM

I was looking at XMPP some time ago, but if I am correct there a tree type of messages (besides the main <stream> message):

* iq
* message
* presence

It looks to me that all extensions are based on these message types. So when using WCF I think that the service methods should be converted in some way to these message types. Something like WebInvoke/WebGet when using REST and WCF. Or am I wrong?

Oct 20, 2009 at 8:10 AM

I've been reading the XMPP spec over the last few days, and i believe that is correct, and seems to be a good plan

Oct 24, 2009 at 5:22 PM

So we're reimplementing the whole XMPP protocol over WCF?  or just getting enough in place to support the Wave Federation Extension to XMPP?


Also it seems to me that one of the first things we should be working on is a implementation of the Operational Transform algorithms, since both the Server and Silverlight client are going to need those.  Just so happens that what I find most interesting about this project :-P

Oct 24, 2009 at 7:04 PM

Yes there are quite a few bits that can be done at the same time. Im working on the XMPP over WCF, i should have something almost finished later next week. I am only implementing the core XMPP spec, then we can add all the extensions & above that.


Oct 24, 2009 at 7:46 PM

Cool; I just realized it too it's going to be a bit more difficult then I suspected to spin off just the OT stuff as a separate library, since the algorithm is closely tied to a network model.  Hopefully we'll be able to pull something out once we start implementing the wave server.


Are you hosting the XMPP WCF stuff anywhere?  The zip file you shared earlier doesn't seem to build for me, and I think other people would be interested in hacking on it :-)

Oct 24, 2009 at 8:11 PM

At the moment in not, once its near done (hopefully next week) i will either put it up on my svn server, OR if i can get dev status here, i can put it up here.

It wont build as its far from complete, i just wanted some feedback on whether i was going in the right direction as it was the first time i have ever done anything this involved in WCF

Oct 29, 2009 at 3:20 PM

Ok i have been doing more research and reading, yet im still failing to see how one actually builds a channel to do what we are trying to achieve (it could be that my lack of experience puts this over my head)

So currently i have worked out that we need / issues im having

  1. a Custom Message Object which can handle the 3 types of message {message, presence, iq} and error messages?? Im stuck on how do we use these in place of the default message class?
  2. i'm also stuck on a Channel can work out if its Server end (listener) or client end

Once i can get that sorted, i think it should be fairly straight forward.

All the documentation i can find about this type of development, only details the building of the plumbing around the channel, not the channel its self.

I have uploaded my updated code here (i will put it in SVN soon, what structure are we going to be using for the SVN?)

If some one could please help with the issues im having, then we can get this moving.