Partilhar via

Community Server Issues - Part I

  • Artigo

Ok, seriously, I have encountered several problems on the web service APIs provided by Community Server during the process of creating this InfoPath blog client. It seems to me the forum at communityserver.org is not very active. Therefore I am posting it here in hope of getting someone's attention.

 

Some of those issues I believe are bugs, some of them might be design changes. But what I really, really do not understand is the soap header change between CS1.0 and the CS version on https://blogs.msdn.com (I believe the latter is newer, pre 1.1, maybe?). Take a look, here is the CS1.0 header:

 

  <soap:Header>
    <BlogCredentials xmlns="https://communityserver.org/blogs/services/posts/">
      <Username>string</Username>
      <Password>string</Password>
      <Blogname>string</Blogname>
    </BlogCredentials>
  </soap:Header>

and here is the msdn one:

 

  <soap:Header>
    <ServiceCredentials xmlns="https://communityserver.org/blogs/services/posts/">
      <Username>string</Username>
      <Password>string</Password>
      <SectionName>string</SectionName>
    </ServiceCredentials>
  </soap:Header>

Due to this change, the client proxy classes of both versions are totally incompatible to each other. In order to work with both, you'd go through two code paths for each web service calls. (Well, someone familiar with reflection might do better, but I doubt it). I, actually ended up creating a separate edition for each of them. What a pain…

 

Of course, there are a few other changes made in the newer versions. Most of them are meaningful and easy to accommodate. For example, the ModerateComments property of the BlogPost class is now changed to a ModerationType enumeration. The functional improvement is obvious. Now what could you get by just changing namings in a published API set, besides introducing incomptabilities?

Comments

  • Anonymous
    May 12, 2005
    Can anyone say Code First Versus Contract First?

    This example is a great example of one of the major issues with the Code First approach that VS embraces, it hides the fact that a change to the underlying class will cause a break in the generated contract. See Aaron Skonnard's Contract First Service Development articles in May and June 2005 MSDN Mag: http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/default.aspx and http://msdn.microsoft.com/msdnmag/issues/05/06/ServiceStation/default.aspx
  • Anonymous
    May 12, 2005
    You are correct. You are not using the same version available for public download yet.

    The web service API is something we did not have enough time to investigate properly in 1.0.

    So in 1.1 we made a couple of changes and improvements. The goal is to lock the CS public API (web service included) by version 1.2 (late summer/early fall).

    The reason for the above change was to make sure Blogs, Gallery and Forums (and others soon) can have a more "common" API. So if/when a gallery web service is published, ServiceCredentials will be re-used.

    HTH,
    Scott
  • Anonymous
    May 13, 2005
    You should be able to modify the client proxy and add fields for each element. With the right XmlElementAttribute, the field would not be null while the other one would.
  • Anonymous
    May 13, 2005
    Don: Great articles.

    Scott: thanks for taking time explaining this. It makes sense in your roadmap. I just hope changes in 1.2 will not be as dramatic as this time. I will have more to say in the coming posts.

    Heaths: I thought about that. It may not be hard. But it definitely will get messy. You can try to unify the client proxy for the following to web referecne:
    1) http://blogs.msdn.com/blogservice.asmx
    2) http://www.trefry.net/blogs/blogservice.asmx
    Please share with me if you do come up with something neat, :-)
  • Anonymous
    July 19, 2005
    A while back, I complained about the big pain caused by the SOAP header change between Community Server...
  • Anonymous
    August 05, 2005
    I've just hit this one, and frankly whatever the reason, it stinks.
    I believe there is a responsibility to provide a degree of consistency for published APIs...but apparently the message should be "don't use the web service because we haven't finished playing with it"...but then MetaWeblog on the other hand has been provided as an add-on, so we can't count on it being added on...

    My patience is sorely tried.