Blogging Roller

Oracle: please follow through on Project SocialSite

2010-03-27T09:10:46+00:00

One year ago on this day I wrote that Sun Microsystems is willing to contribute Project SocialSite" to the Apache Software Foundation. My contacts at Sun told me it was OK to make that announcement because a VP approved. One year later, we have established Apache SocialSite (incubating) project, setup user accounts, put up a status page and setup source code control but we still have no code from Sun.

Since March 2009 I've been exchanging emails with my helpful contacts at Sun and trying to help them move forward with the contribution, but because of the ongoing Oracle/Sun merger things have moved incredibly slowly. Finally in late December 2009, my Sun contacts had permission to actually release the code to Apache, but there was a problem.

When Sun said that they were willing to contribute the SocialSite code to Apache, I figured that they would do so using the standard Software Grant agreement that was used for Roller and all other projects entering Apache via the Incubator. Unfortunately, the Sun lawyers did not want to use the standard Software Grant agreement and Apache did and does not want to devise a new legal agreement just to accommodate Sun. That's where we stand today. Sun committed to contributing SocialSite to Apache and now we're waiting for Oracle/Sun to follow through on that commitment.

Meanwhile, others have been making some progress with SocialSite. A major sports brand has launched a SocialSite based network with a million-plus users. A couple of developers have rewritten the build script to use Maven, others have "ported" to JBoss and there is still interest in and a need for what was Sun's Project SocialSite. Neither effort has contributed code back to SocialSite-proper and because of legal concerns are waiting for the main code to appear at Apache.

SocialSite is a small project and it will not survive for much longer with resources spread across multiple sites and a community working separately. So, I'm asking again and publicly: Oracle, please follow through on your commitment and grant the Project SocialSite codebase to Apache.

IBM at last month's Enterprise 2.0 OpenSocial panel

2009-12-14T13:32:02+00:00

It's been over a month since the Enterprise 2.0 OpenSocial panel and since we were never able to get a group blog post together, I've decided to publish a short summary of what I said about IBM on the panel. I'm paraphrasing myself from memory so this is not exactly what I said but it should be pretty close:

IBM has been successfully innovating in the area of browser-based components, also known as widgets or gadgets, and social APIs for years now. If you haven't seen the IBM Mashup Center you should visit the IBM booth and take a look at the demo. It allows you to create Web 2.0 style mashup applications by dragging-and-dropping widgets into place and wiring them together. You've probably heard of Lotus Connections. Connections is IBM's social software suite and it includes blogs, wikis, forums, social bookmarking and more. Each one of those components features a comprehensive AtomPub-based REST API.

We're working with the OpenSocial community to ensure that the specification meets the needs of our customers and is able to interoperate with our existing iWidget technology (and I think I mentioned the OpenAjax Hub here too). You can see most of the improvements that we're interested in the slides, so I won't go into detail now, but I will mention a couple of things for example: we would like to see better inter-gadget communication, specification modularity (coming in OpenSocial 1.0) and a stable and predictable specification change process.

I work for Rational, the part of IBM that creates tools for software development and delivery, something that is also social and collaborative in nature. We're enthusiastic about OpenSocial and we hope to enable use of OpenSocial Gadgets in Jazz-based product dashboards sometime in 2010. We may also support some of the OpenSocial Social APIs, but we are still learning and experimenting. Jazz products are developed in an open and transparent way so you can track our progress via our wiki and work-items at Jazz.net.

I won't try to paraphrase what the other panelists said, I'll let them do that, and I'll leave out my SocialSite pitch for now as most of my readers have already heard it. I'll put together an update on SocialSite during the next month and I think I'll have some good news to report.

Trip report: ApacheCon US 2009

2009-11-15T10:59:18+00:00

(Last week, I returned after a week of vacation and a week of conferences in the SF bay area. Instead of posting my trip reports to the limited audience that reads my internal IBM blog, I'm going to post them here so that everybody can benefit from them.)

Here's my report from ApacheCon US, focusing on the projects I'm involved with: Roller, Shindig and SocialSite.

Roller session#

In my session, I covered the new features in 5.0, Roller history and sort of a Roller state of the union. I explained that nobody is working full-time on Roller these days, it's an all volunteer effort with about three people active and if folks want us to keep on making official Apache releases then those very same folks had better step-up and get involved so we can knight some new PMC members. I also did a demo of the new features in Roller 5.0 including OpenID and the file upload and management improvements.

What's new in Apache Roller 5.0, Dave Johnson
http://www.us.apachecon.com/c/acus2009/sessions/280
Announcement: Roller 5.0 beta 1 available
http://markmail.org/message/rwk6pj4voxbyuaj3

Shindig session#

After my Roller talk and in the same room, I attended Paul Lindner's talk on Apache Shindig. Paul has worked on OpenSocial implementations at Hi5 and LinkedIn and he's also a committer on the Apache Shindig project.

Empowering the Social Web with Apache Shindig, Paul Linder
http://www.us.apachecon.com/c/acus2009/sessions/281

I'm familiar with Shindig so this was mostly review for me. I liked Paul's assessment of Shindig quality, saying that they have good processes in place, use code reviews and have good test coverage. Paul acknowledged problems with Shindig's developer friendly-ness and said that the community is working to fix them. I've heard similar complaints from multiple source and seen myself that it's not as easy as it should be to understand the codebase, figure out how to plug-into it and understand which parts are really required for OpenSocial and which are just sample code.

Paul also talked about the Open Stack concept, a set of open standards that enable social networking interoperation including OpenSocial, ~OAuth, OpenID and portable contacts. He said that Shindig is the best way to implement the stack and keep up with the evolving standards. He had a nice quote about "Shindig is to OpenSocial as Apache HTTPD is to HTTP"

Social Widgets / Gadgets meetup#

On Thursday night, I attended Social Widgets / Gadgets meetup which brought together members of the Apache Shindig, Apache SocialSite and Apache Wookie Communities.

Apache Shinding: OpenSocial Reference Implementation
http://incubator.apache.org/shindig
Apache SocialSite: Headless Social Networking server plus Gadgets
https://socialsite.dev.java.net/
Apache Wookie: W3C Widgets, OpenSocial and Wave Gadgets server
http://incubator.apache.org/wookie

There were about 25 people there including folks from Google, Atlassian, Yahoo, Ning, LinkedIn, Hippo (CMS/portals ISV) and, I'm guessing, a bunch of SF bay area startups. The meetup started around 8PM and lasted over two hours.

I presented a lightning talk on Apache SocialSite using a couple of slides from the JavaOne talk and including a quick status report. Status is this: still waiting on Sun to come through on code grant, Globant is having some success with SocialSite in production and work is almost complete in converting the build over to Maven. I also did a quick talk about the Enterprise 2.0 OpenSocial panel, which occurred the day before.

SocialSite Mavenized
http://code.google.com/p/socialsite-mavenized

Next, Jas Nagra did a very entertaining and informative mini-presentation on Caja, complete with XMen 2 references. Caja is a way to run Javascript code (e.g. gadgets) loaded from different locations, each in its own secure sandbox where it can't interfere with others and can't do evil -- but without relying on iframes. Shindig uses Caja, but it's optional and off by default.

Google Caja - A source-to-source translator for securing Javascript-based web content
http://code.google.com/p/google-caja/

After that Paul Linder did a quick talk on the Open Stack idea and revised his Shindig quote to "Shindig is to the Open Stack as Apache HTTPD is to HTTP." Then we broke up and folks stuck around to talk about APIs, projects, possibilities and everything else for quite some time.

That's all I've got for now. I hope to document some of my experiences on the "Enterprise OpenSocial" panel at Enterprise 2.0 later, possibly in a blog post on the OpenSocial blog.

ApacheConUS 2009 registration open, sign up now!

2009-08-11T20:09:21+00:00

The early-bird special ends on August 14, so you'd better get moving.

Sign up for ApacheCon US by 14 August and save up to $500!

This year's ApacheCon US promises to deliver our most extensive program to date, and largest anticipated gathering of the global Apache community to celebrate the ASF's milestone 10th Anniversary. The San Francisco Bay Area is where the very first ASF official user conference was held, and we hope that you will join us in celebrating the ASF's success!

Apache members, code contributors, users, developers, system administrators, business managers, service providers, and vendors will convene 2-6 November in Oakland, California, for a week of training, presentations, sharing and hacking. ApacheCon US 2009 features new content tracks, MeetUps, and GetTogethers, as well as a number of events open to the public free of charge, such as the Hackathon and 2-day BarCampApache, in appreciation of their support over the past decade.

Be sure to register by 14 August to save up to $500! To sign up, visit http://www.us.apachecon.com

I'll be there and speaking on the topic of What's New in Roller 5.0. I also plan to attend the Social and Widgets Meetup with folks from Shindig, SocialSite and Wookie. I hope to see you there.

SocialSite@Apache

2009-04-23T23:00:49+00:00

I took a break from blogging during my first couple of weeks at IBM. My blog broke and it took me a while to find the time and motivation to fix it, but now it's time to return. I think. I have been doing some internal blogging at IBM, but so far it's been mostly boring stuff: status reports and the like.

What I want to talk about today is Project SocialSite. Since my last post, where I mentioned that Sun is willing to contribute SocialSite to Apache, I did some work to move things along. I wrote an Apache Incubator proposal, started a discussion and this week calling for a vote on the proposal. Here are the relevant links:

Proposal: Apache SocialSite

Discussion and vote thread on the Incubator General mailing list

Subscripton info for the Incubator mailing lists

If you want to support the project, and especially if you're on the Incubator's Project Management Committee, now's the time to do so.

The future of Project SocialSite: Apache?

2009-03-27T13:17:27+00:00

Since January, the future of https://socialsite.dev.java.net">Project SocialSite has been in the hands of the SocialSite community. During that time, I continued working on the project almost because I think it's got great potential and I would really like to see it live on in some form. That's also why I continued to talk to Sun about the project.

Today, I'm very happy to announce that Sun Microsystems is willing to contribute Project SocialSite to the Apache Software Foundation. It's not clear whether SocialSite should be contributed into Shindig or as a new incubator project, but either way I think this is the best thing for the project and will give it the best possible chances for building a thriving community. I've started some discussions about this on Apache-private mailing lists and I'll let you know what happens next.

This post brings to an end my series of posts about Shindig for blogs and wikis. Here are links to the earlier posts:

By the way, I delivered my Shindig talk just a couple of minutes ago. It was well-attended and I think it went pretty well. You can find the slides online at the ApacheCon EU 2009 site here: http://www.eu.apachecon.com/c/aceu2009/sessions/184">Shindig for Blogs and Wikis. Now back to your regularly scheduled programming...

OAuth everywhere (continued)

2009-03-26T02:00:00+00:00

In my earlier OAuth everywhere post I explained at a high level "how I got a Roller Gadget working, one that uses OAuth to call Roller and enables Roller to use OAuth to call back to the social network." I ended with some unanswered questions:

How do I add my gadget to SocialSite so users can install and use it?
How does SocialSite get the Consumer Key and Secret needed for calling Roller?
How does Roller get the Consumer Key and Secret needed for calling SocialSite?
How does the user authorize Roller's access to his Profile information in SocialSite?
When is OAuth support coming to the Roller trunk and can you use it for AtomPub?

(that last question was answered in OAuth for AtomPub in Roller earlier this week)

Now that I've wrapped up my work on OAuth in SocialSite and OAuth in Roller, I'm prepared to answer those questions. I'll do it by reviewing how I developed my Social Roller gadget and set it up to work on http://rollerweblogger.org, my Roller and SocialSite powered site.

Along the way, I'll provide links to source code and screen-shots. I'll be referring to the diagram from first post, so I'll reproduce it here for the sake of convenience:

NOTE: this post is based on the current code in the Project SocialSite SVN trunk. The things described below WILL NOT work with the SocialSite M3 release.

Step 1 - Develop an OpenSocial Application#

My first step was to develop an OpenSocial application for Roller. This application is made up of the three parts listed below. These are the parts show in light-blue in the diagram above.

An OpenSocial Gadget for Roller that a user can install into his SocialSite profile. An OpenSocial Gadget is defined by Gadget Specification, an XML file with the metadata, HTML, CSS and JavaScript that render the gadget's user interface. I developed my gadget as a Roller page template and you can view it's source code here: gadget.xml
A gadget setup page, a new JSP page in Roller that is called by the gadget to enable and disable Activity posting. This JSP page is protected by OAuth and returns data in JSON format to the gadget. View the source code here setupgadget.jsp
A Roller Task that runs periodically, checks to see if any gadget users have created new blog posts and if they have, posts a Activity to SocialSite for each, by calling the OAuth-protected OpenSocial REST API provided by SocialSite. View the source code here SocialRollerTask.java

Step 2 - Register gadget with SocialSite#

This section answers the question "How do I add my gadget to SocialSite so users can install and use it?"

My next step was to register my application. Remember that SocialSite is intended to add social features to existing web sites and has very little user interface of its own, it's mostly made up of gadgets. So, the way you register a new application on a SocialSite-enabled site is to sign-up as a user of that site, go to your profile page, install the SocialSite Developer Gadget and then use that gadget to register your new application.

You can see a screenshot of the SocialSite Developer Gadget below. In the simplest case, you just enter the URL of your Gadget Specification, but I needed to take a couple of extra steps because my gadget needs to call an OAuth protected resource in Roller.

This next paragraph answers the question "How does SocialSite get the Consumer Key and Secret needed for calling Roller?"

I need my gadget to call back to the Roller setupgadget.jsp page (that's part #4 in the diagram above) to enable/disable activity posting. Because that page is protected by OAuth, I had to go into Roller and get Roller's site-wide OAuth key and secret (see also: OAuth for Roller) and then enter those it the Developer Gadget. SocialSite stores them and will use them to take care of the OAuth authentication process on each gadget call to Roller (in part #2 above).

Step 3 - Approve gadget registration#

Since I'm the administrator of my site, I approved my own gadget registration. I did this by logging into my site's SocialSite admin console, went to the Gadget Management tab, saw my new gadget registration request and approved it. Here's a screenshot of the Gadget Registration approval page:

Step 4 - Add OAuth consumer key and secret to Roller#

This next paragraph answers the question "How does Roller get the Consumer Key and Secret needed for calling SocialSite?"

After your gadget is approved for use on a SocialSite enabled site, you'll find the consumer key and secret that Roller needs to call the OpenSocial REST API (that's step #6 above) in the SocialSite Developer Gadget. Here's what you see in the Developer Gadget once you gadget is approved.

My OpenSocial Roller application needs to know about those keys, so I put them in its configuration. For simplicity's sake, I'm not going to go into the details of this step.

Step 5 - install the Social Roller gadget#

Finally, the OpenSocial Roller application is ready for use. To install it, I went to my profile page, clicked the Gadget Directory button, browsed through the gadgets until I found it and then clicked the install button. Here's a screenshot of the SocialSite Gadget Directory, which you can access from the SocialSite Profile Gadget:

The Social Roller Gadget is the last item in the list, the "Simple Roller Gadget."

Step 6 - authorize and enable the Social Roller gadget#

After I installed the gadget, it appeared in my Profile page as you can see in the screenshot below. It's installed and ready to run, but it's not yet authorized to access my Roller account so it tells me "Before you can use this gadget, you must authorize it to access your Roller account."

Finally, I can answer the question "How does the user authorize Roller's access to his Profile information in SocialSite?"

I want the gadget to access my Roller account so I clicked on the authorize link and saw this page popup, directly from Roller, which asks me to take the final step to authorize access.

After I clicked the authorize button, page disappeared and the Social Roller gadget redisplayed itself as you can see in the screenshot below. The gadget is now ready to access my Roller account and is asking me to enable activity posting:

I clicked the enable posting button and saw this:

And now, whenever I post a new blog entry, an activity is added to my profile. Here's proof in the form of a screenshot:

Conclusion#

I've done the work to enable OAuth in SocialSite and Roller, so now it's possible to develop OpenSocial gadgets for Roller that will work with SocialSite and other OpenSocial containers. The Roller side of this work is now available in Apache Roller (in the SVN trunk), but the future of the SocialSite is still uncertain.

I think SocialSite still has great potential. That's why I'm spending so much time promoting it and moving it forward, but I can't do it all myself. I'm joining IBM next week and as far as I know, SocialSite will NOT be part of my job. I'll wrap up this series of posts tomorrow with a post discussing the future of Project SocialSite.

Socialsite on rollerweblogger.org

2009-03-25T23:59:59+00:00

The value of Project SocialSite is that it allows you to add social networking features, including the ability to run OpenSocial gadgets, to existing web sites and have those sites all using the same "social graph" of data about people and relationships. To demonstrate this, I've deployed SocialSite to my site, http://rollerweblogger.org, and finally implemented those things I described in my August 2008 Social Roller post (except for protected entries).

My site includes a blog and a wiki, Roller and JSPWiki, so it's a pretty good candidate for demonstrating how SocialSite can work with multiple existing webapps. It's not perfect because it's got a very small number of users, less than a dozen, and because it's private; you have to login to see the social features, but it'll have to do. In this post, I'll explain the steps you have to take to add SocialSite to a multi-application web site and I'll illustrate the steps with examples, links to source code and screenshots from my work on this site.

NOTE: this post is based on the current code in the Project SocialSite SVN trunk. The things described below may or may not work with the SocialSite M3 release.

Step 1 - Setup an Authentication Delegate page in your site#

SocialSite doesn't do any user management, it leaves that to the sites that it enables. In my case, I've got Roller and JSPWiki setup to authenticate against the same database table of usernames and passwords, and I've got Tomcat's simple SSO setup so that logins work across both webapps. I want SocialSite to depend on Roller to verify that users are logged. SocialSite's Authentication Delegation mechanism makes this possible.

Here's how SocialSite Authentication works. You add a delegate page, a dynamic page (JSP, PHP, etc.) to the webapp that is to do the authentication, configure SocialSite to trust that webapp and then at runtime, SocialSite will call that delegate page to verify user logins. In my case, I want Roller to do the authentication so I added a delegate page to Roller called socialsite_context.jsp.

When a SocialSite gadget running inside of Roller needs to call back to the OpenSocial API provided by SocialSite it will pass Roller's login cookie with the call, an assertion about who the logged-in user is and the URL of Roller's authentication delegate page (socialsite_context.jsp). SocialSite will then call that delegate, pass the cookie and verify that assertion. SocialSite expects the delegate to return some JSON data like this:

Example: JSON data from socialsite_context.jsp


  {
    'timeout': 30,
    'assertions': {
      'containerId': 'rollerweblogger.org',
        'viewer': davej,
        'owner': davej,
      }
    }
  }

In the above example, Roller is confirming the assertion that the user is 'davej' and the owner of the page containing the gadget is also 'davej'. Knowing this, SocialSite can decide what data the caller is allowed to access.

Step 2 - configure SocialSite to trust your Authentication Delegate page#

SocialSite won't trust just any authentication delegate page. Once you have created your page, you must configure SocialSite to trust it. You do this by editing a SocialSite configuration file in WEB-INF/classes/socialsite_context.xml. Here's an example that sets up a trust relationship with Roller's socialsite_context.jsp page:

Example: socialsite_context.xml in SocialSite


  <rules>
    <rule>
      <sources>
        <indirect>*</indirect>
      </sources>
      <assertions>
        <reject>*</reject>
      </assertions>
    </rule>

    <rule>
      <sources>
        <direct>http://rollerwebogger.org/socialsite_context.jsp</direct>
        <direct>*</direct>
      </sources>
      <assertions>
        <accept>*</accept>
      </assertions>
    </rule>
  </rules>

Step 3 - Add SocialSite Context declarations to target pages#

Once the Authentication Delegate page is in place, you're just about ready to start adding gadgets to the pages of your web applications. Each page that includes gadgets will need to include a couple of SocialSite scripts and information about the SocialSite context, i.e. the URL of the authentication delegate. Here's an example of the the JavaScript that I include include in Roller pages that use SocialSite gadgets:

Example: SocialSite context declaration for a Roller page template


  #set($viewer = $utils.getAuthenticatedUser().getUserName())
  #set($userName = $model.getRequestParameter("user"))
  #if ($userName)
    #set($owner = $userName)
  #else
    #set($owner = $viewer)
  #end
  #set($contextURL = "${url.absoluteSite}/socialsite_context.jsp")
  <script type="text/javascript" 
    src="${url.absoluteSite}/social/js/consumer.jsp"></script>
  <script type="text/javascript">
    socialsite.setContext({
      'delegate': {
        'method': 'GET',
        'url': '$contextURL?owner=$owner&amp;viewer=$viewer',
        'headers': {
          'cookie': document.cookie
        }
      }
    });
  </script>

The above code pulls in some JavaScript from SocialSite and sets up the context necessary for gadgets to call back to SocialSite. It uses Roller's $utils.getAuthenticatedUser() to determine the logged-in user and a request parameter 'user' to determine who owns the page.

Step 4 - decide where to put key social networking pages#

Finally, you're ready to add gadgets to the pages of your site. First, you'll want to do some planning. You'll want to decide where to place some key pages. The SocialSite widgets are designed to support a dashboard page, which allows users to browse people, make friends and receive messages. They also support both personal and group profile pages.

For rollerweblogger.org, I decided to use one Roller page template 'people' to act as both the Dashboard and Profile page. If you access the page with a URL that specifies a user, then you'll see the profile page of that user. If you access the page with without specifying a user, then you'll see your dashboard page. Here's what I put in the socialsite.properties file to set all this up:

Example: SocialSite URL properties from socialsite.properties


  # People page shows your Dashboard
  socialsite.dashboard.url=\
    http://rollerweblogger.org/project/page/people

  # People page with user parameter shows profile of specified user
  socialsite.profile.url=\
    http://rollerweblogger.org/project/page/people?user=${userid}

  # Group profile page will be hosted in JSPWiki
  socialsite.group.url=\
    http://rollerweblogger.org/wiki/Wiki.psh?page=${groupid}

NOTE that in the above configuration, I'm using my wiki to host group profile pages; more about that later.

Step 5 - add OpenSocal Gadgets#

Once you've decided how to set things up, you're ready to start adding gadgets. Assuming that you've added the SocialSite context declarations in your pages, you can add a gagdet with a single line of JavaScript. For example, to add the SocialSite Owner Activities Gadget you'd add this code:

Example: add gadget code from a Roller page template


  <script type="text/javascript">
    socialsite.addGadget({'spec':'local_gadgets/owner_activities.xml', 
      'removable':false, 'height':75, 'includeChrome':true});
  </script><br/><br/>

NOTE that you can add any OpenSocial gadget by specifying its URL in the spec argument of the socialsite.addGadget() call.

Screenshots#

It's screenshot time. I've included small thumbnail images belo, which you can click for a closer view. If you're on my site, photos will display in a light-box. First up, is the new People page that you will see if you are logged into rollerweblogger.org. It uses the SocialSite Profile, Face, Status, Friends and Activities gadgets.

Next up, the dashboard page. It uses just one gadget, the SocialSite Dashboard, which provides a bunch of different features and was introduced in the SocialSite M2 release. In one tab you can see the most recent activities of your friends or any of your groups:

In the second tab of the Dashboard Gadget, you can search and filter the people in the social network. You can filter by friends or by your groups. You can also create new relationships and accept or ignore relationship requests from this view.

In the last tab of the Dashboard Gadget, you can view and manage incoming messages and friendships requests:

Want to see the source code? You can see the page template code for my People page in the Roller page templates people, which contains the SocialSite context declaration, and people, which contains the main body of the page.

Finally, let's take a look at an example group profile page, which is located in my wiki.

Hmm... I never explained how I got SocialSite gadgets working in JSPWiki. Better fix that now.

A note about SocialSite in JSPWiki#

To get SocialSite gadgets working in JSPWiki, I had to to a little extra work. In my instance of JSPWiki, I don't allow HTML so I couldn't just drop in the JavaScript code necessary to declare the SocialSite context and make the socialsite.addGadget() calls. What I had to do was to create a couple of JSPWiki plugins, one for the SocialSite context and one for the add-gadget call. Here the raw wiki text of the Atomic Group page pictured above:


  !!!SocialSite Group: Atomic

  [{SocialSiteGroupContext group='atomic' 
    consumerUri='http://rollerweblogger.org/social/js/consumer.jsp' 
    authUri='http://rollerweblogger.org/socialsite_context.jsp'}]

  Demonstrates the SocialSite Group gadgets, running in JSPWiki.

  !!Group Profile Gadget

  Below is the Group Profile for group __Atomic__. You can use the buttons at 
  the bottom to edit the group's profile properties, to send a message to 
  the group and to add OpenSocial gadgets to this page.

  [{SocialSiteAddGadget spec='/local_gadgets/group_profile.xml' removable='true'}]

  !!Installed Gadgets

  This is where the group's OpenSocial gadgets will appear.
  [{SocialSiteAddGadget collection='GROUP'}]

And here are links to the source code for the two plugins: SocialSiteContext.java and SocialSiteAddGadget.java.

Conclusion#

That should give you a pretty good idea of what you can do with SocialSite. Don't be dissappointed if the gadgets don't look like exactly what you want. The important thing is that SocialSite gives you a centralized social graph service and the infrastructure needed to add social networking features to your sites via OpenSocial gadgets. If you don't like the gadgets that come with SocialSite, you easily write your own using the standard OpenSocial APIs and the SocialSite extensions to those APIs.

Leaving Sun...

2009-01-22T17:23:11+00:00

It was over four years ago when I discovered that Sun was using my software, Roller, to power blogs.sun.com. I was thrilled to go to work for the company back in 2004 and what an awesome cast of characters I've gotten to work with over the years. I really enjoyed the folks I worked with on the blogs.sun.com team, the open source folks and most recently, the Glassfish team -- some of the most talented and nicest folks I've ever worked with. It's been a great four and a half years but all good things must come to an end and today is the day.

I've been swept up in the latest round of Sun layoffs. Sun has decided to disinvest in Project SocialSite and as of today I'm free and available for employment. Though I do feel some urgency due to the bad economy, Sun's layoff package is pretty good and so I have some time to figure out what comes next and no need to make hasty decisions. Whatever I end up doing, I'll be blogging it here.

Oh, and about Apache Roller and Project SocialSite? I'm not ready to give up just yet. I'll be using a little of my time to do some mentoring and to move forward plans for Roller 5.0 this spring. And I see real value in the Project SocialSite "social-enable existing web sites" concept and I'm considering ways to move that forward as well, with or without Sun. I'm still giving my talk Shindig for Blogs & Wikis in March 2009 and, actually, I'm pretty happy I have some time right now to focus on those demos and slides.

Google's Rajdeep Dua on Project SocialSite

2009-01-20T16:58:51+00:00

I'm always happy to see Google talking about Project SocialSite in their OpenSocial presentations and pitches. We need all the help we can get with getting the word out.

Now, Rajdeep Dua of Google Developer Relations has put together a 25 page presentation on Project SocialSite Architecture with data model diagrams, UML and lots of detail. Good stuff. I posted some comments and corrections to the Shindig-dev mailing list

SocialSite's Flexible Relationship model

2008-11-19T10:47:21+00:00

Image by flawedartist

We're designing Project SocialSite to support the needs of any site that wishes to add Social Networking features and support OpenSocial. That means we have to be flexible.

We can't hard-code the names of different types of relationships because some sites might want to call friends "buddies" and some might call them "connections." Some sites might want multiple levels of relationships, with some relationships being considered stronger than others, like on Flickr where you have contacts, friends and family. Some sites might want to allow one-way relationships, as Twitter does with "followers," but some sites might want to require that relationships be two-way, as Facebook does.

We want SocialSite to have a Flexible Relationship model that a site operator can tweak to suit the unique requirements of her site's community. We've settled on a model based on relationship types and named levels. In this post, I'll review this new model that we have designed in hopes of getting some feedback, push-back and other good things that might help us refine our model.

I) Relationship Types

SocialSite is designed to support the types of personal relationship shown below. This doesn't include group relationships, which are handled separately.

One-way relationship: A relationship from one person to another person that is not reciprocated. For example, Fred has a relationship with Bob, but Bob has no relationship with Fred. Another example: a follower relationship as you see in Twitter.
Two-way relationship: A relationship from one person to another that is reciprocated. For example, Fred has a relationship with Bob and Bob also has one with Fred. Another example is Facebook, which requires friendship relationships to be two-way.
Mutual relationship: Fred and Bob have a two-way relationship and have agreed on a "how we know each other" message. This is more meaningful than a two-way relationship, because the two parties have agreed on some shared item of information about the relationship like "we met at band camp."

II) Relationship Levels

SocialSite can be configured to support multiple relationship levels like Flickr's contacts, friends and family levels. Users can use these levels when sharing information, e.g. share a photo only with relationships of family-level or higher. I'll explain how the configuration works, but first let's define what we mean by relationship level.

Relationship Level

A Relationship Level is a named integer index that is assigned by one person to indicates the strength of a relationship with another person. People only know the levels that that they have assigned to relationships, so one person in a relationship won't feel slighted if the other party thinks less of the relationship than they do. For example, Fred might consider Bob to be a level 2 "Close Friend" but Bob considers Fred only a level 1 "Acquaintance" relationship. Fred won't learn about this (unless Bob tells him).

You can configure the relationships levels and names supported by SocialSite via the property 'socialsite.relationship.levels'. You simply provide a comma separatied list of the I18N keys of the relationship level names, in order from no-relationship to the strongest level. Here is the default setting, which establishes three relationship levels 0=none, 1=contact and 2=friend:

  socialsite.relationship.levels=\
  relationshipLevel.none,\
  relationshipLevel.contact,\
  relationshipLevel.friend

OpenSocial doesn't define differently named relationship levels like we do, so we need to do some mapping. OpenSocial has one type and one level of relationship called "friend." So, to map SocialSite relationships to OpenSocial, we have introduced the notion of a friendship level.

Friendship level

Friendship level is an integer configuration property which indicates the relationship level that is considered to be the friendship relationship across a SocialSite system. Relationships at or above this level are considered to be friends when returning data via OpenSocial APIs. Also, when you add a relationship at friendship-level or above, the other party will be notified and given the opportunity to add you as a friend too. You can configure the friendship level via the property below:

  socialsite.relationship.friendshiplevel=2

It's good to have the flexibility to support both one and two-way relationships, but we can't assume that all sites will want both. Some social network services, like Facebook, require that friendship-level relationships be two-way, i.e. both parties must agree that they are friends. To make such a setup possible with SocialSite, we've introduced the configuration property below:

  socialsite.relationship.twoway.requiredForFriendship=true

If that property is true, then any relationship that is considered a friendship (relationship level >= friendship level) must be a two-way relationship. So, when you add a relationship at friend-level or above, the other party must reciprocate or the relationship will not be created.

III) Example SocialSite configurations

To better explain how SocialSite Flexible Relationships work, here are some example configurations that configure SocialSite to behave like well-known social network services.

-like configuration. Flickr supports relationship levels of Contact, Friend and Family. It's possible for you to consider somebody to be Family, while they only consider you only to be a Contact. Any level relationship is considered to be a friendship relationship, for the purposes of OpenSocial.

  socialsite.relationship.levels=\
     relationshipLevel.none,\
     relationshipLevel.contact,\
     relationshipLevel.friend,\
     relationshipLevel.family
  socialsite.relationship.friendshiplevel=1
  socialsite.relationship.twowayRequiredForFriendship=false

-like configuration. Twitter supports one relationship level and that is follower. Its possible for you to follow somebody that does not follow you.

  socialsite.relationship.levels=\
     relationshipLevel.none,\
     relationshipLevel.follower
  socialsite.relationship.friendshiplevel=1
  socialsite.relationship.twowayRequiredForFriendship=false

-like configuration: Facebook supports one relationship level and that is friend. Friendships are required to be two-way, so we have this:

  socialsite.relationship.levels=\
     relationshipLevel.none,\
     relationshipLevel.friend
  socialsite.relationship.friendshiplevel=1
  socialsite.relationship.twowayRequiredForFriendship=true

The default SocialSite configuration. We're considering the below settings for our default configuration. This would allow you to have contacts, with which you can share information but who are not considered friends and would not show up in your friends list or be returned as friends via the OpenSocial APIs.

  socialsite.relationship.levels=\
     relationshipLevel.none,\
     relationshipLevel.contact,\
     relationshipLevel.friend
  socialsite.relationship.friendshiplevel=2
  socialsite.relationship.twowayRequiredForFriendship=true

IV) Wrapping up...

That just about covers it, so I'm going to wrap up now. Most of the above is now implemented in SocialSite, but none of this stuff is carved in stone. So your feedback is more than welcome, either here or on the SocialSite development or user mailing lists.

The X-rated SocialSite API

2008-10-20T10:48:38+00:00

Roy Fielding: I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today's example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

Ouch! As the author of the torrid (and pretty rough) Project SocialSite Proposal: Finalize Web Services APIs proposal that Roy calls out to sharply, I'd like to point of that, as I explained in a recent post, Project SocialSite is simply implementing and extending the OpenSocial API. OpenSocial includes both a JSON-RPC API and a REST API. SocialSite implements and extends them both. I never meant to imply that the JSON-RPC API is RESTful (and neither did the authors of the OpenSocial specifications). In fact, I renamed the proposal from "Finalize REST APIs" to "Finalize Web Services APIs" after I realized that OpenSocial would come in both flavors.

The proposal that I wrote outlined a way for Project SocialSite to hook into Apache Shindig (incubating), the Reference Implementation of OpenSocial,implement a couple of Shindig interfaces and thus gain support for both the OpenSocial REST API and the OpenSocial JSON-RPC API. The OpenSocial REST API does claim to be RESTful and I believe it is; it's based on AtomPub but includes some extensions for providing generic XML and JSON representations in addition to Atom format. The Project SocialSite REST API will extend that and will also be RESTful.

SocialSite's Opensocial extensions, part 1: Web services

2008-10-15T17:45:54+00:00

I'm on SocialSite blog patrol this week, which means that I need to post interesting stuff at blogs.sun.com/socialsite, or here or both places at once.

So here's some blog fodder, a series of posts describing the extensions we are making to OpenSocial for Project SocialSite. I'll start by describing the web services, then the JavaScript API and finally I'll provide an example or two.

Background

As I may have mentioned before, the idea behind SocialSite is to add Social Networking features to existing web sites and applications. Any site or sites should be able to use our Widgets and Web Services to all the standard Social Networking features. To meet our Widget requirements we have to extend OpenSocial to support full read/write access to Social Graph data with support for "friending" with configurable relationship levels, profile editing, group invites, group management, application management and other things.

A word about implementation

On the server-side, our extensions are implemented as Shinding/Java DataRequestHandlers, which makes them available as both a REST API and a JSON-RPC interface. This means that they're available in a form very similar to that of the standard OpenSocial REST API and in a form very similar to the standard OpenSocial JSON-RPC API.

To give you an overview of the SocialSite extensions, I'll review the REST form of our APIs including all of the URIs we support and the HTTP verbs we support for each.

td.uri { width:40%; font-family: Courier; font-size: 10px; } td.data {width:5%; font-family: Courier; font-size: 10px; } td.verbs {width:55%;} td.uri, td.verbs, td.data { border-bottom: grey dotted 1px; vertical-align: text-top} td.routetitle {background: #efefef; color: black; padding: 3px;} table.apiref {width:100%; font-size:13px; margin-bottom: 0.5em;}

People and friending

The standard OpenSocial APIs don't support "friending" -- the process of requesting and negotiating some form of social relationship with another user. So, we've added some new URIs to the /people route in OpenSocial because support . These URIs return and accept standard OpenSocial Person objects, for example to request a relationship with somebody, you POST a representation of that person to your @friends collection.

People
/people/{userId}/@friends	Person	POST - Person to request or accept relationship
/people/{userId}/@requests	Person	GET - List of Persons requesting relationship
/people/{userId}/@requests/{personId}	n/a	DELETE - ignore a Person requesting relationship
/people/{userId}/@friends/{personId}	n/a	DELETE - remove relationship with Person

Profile editing and metadata

The standard OpenSocial APIs don't support creating and updating profile data. So, we've added new /profile and /profiledef routes to enable metadata driven profile property editing. You can create, retrieve and update profile properties for each user. You can also get metadata that defines all profile properties, their types and accepted values.

Profiles
/profiles/{userId}	Profile	GET - SocialSite profile data properties for one user PUT - Update profile data for one user
/profiles	Profile	POST - add a new profile via SocialSite profile data properties
/profiledef	ProfileDefinition	GET - SocialSite profile property metadata in JSON format

Profile Privacy Settings

The standard OpenSocial APIs don't give you any control over who can see which parts of your profile or activities. So, in the standard SocialSite setup, we have grouped the standard OpenSocial properties into seven sections: identification, contact, extended contact, personal, more personal, experience and education. For each of these sections you can choose a visibility level; here they are from most restrictive to least: private, friends only, visible to some your groups, visible to all of your groups and public.

Privacy settings
/sectionprivs/{userId}	List of SectionPrivacy	GET - section privacy settings for user
/sectionprivs/{userId}/{sectionName}	SectionPrivacy	GET - section privacy setting for one profile section PUT - update section privacy setting for one profile section

Group creation, management and invitations

The standard OpenSocial APIs don't support any group creation, management or invitation capabilities. So, we added those too. Like SocialSite Profiles, Groups have properties which are defined by a metadata definition file. Here are the URIs and HTTP verbs for each:

Groups
/groups/@public	Group	GET - all public groups POST - create a new public group
/groups/@public/{groupId}	Group	GET - group specified by group ID
/groups/@public/@current	Group	GET - owning group specified by context (security token)
/groups/{userId}	Group	GET - all of user's groups
/groups/{userId}/@friends	Group	GET - all of user's friend's groups
/groupdef	GroupDefinition	GET - SocialSite group property metadata in JSON format

Looks like that's all I have time for today. Dinner time is here I'll cover the rest of the Web Services in part 2, later this week.

Project SocialSite Webinar, Thursday at 11:15am PT

2008-10-08T08:56:43+00:00

If you want to learn more about SocialSite, here's your chance. I'll be doing a SocialSite webinar tomorrow (Thursday, Oct. 9) at 11:15am PT. Here's the summary.

Project SocialSite is taking a new approach to social networking. Instead of replacing your existing web site with a Social Networking system, SocialSite allows you make your existing blogs, wikis, forums and portals social and all backed by the same Social Graph of users. It doesn't matter whether your existing applications are Java, Ruby, PHP or blog/CMS template driven, you can easily add the SocialSite Widgets and and give your users a complete Social Networking experience right in the pages of your existing site. You'll be able to provide Personal Profile and Group Profile pages, a Dashboard for your users to manage their groups and connections and allow your users to install standard OpenSocial Gadgets that operate against their network of friends. Your applications can manage the social graph via the SocialSite web services and via standard OpenSocial Gadget technology.

In this webinar we'll explain the reasoning behind Project SocialSite, the basics of OpenSocial and what SocialSite adds, the SocialSite architecture and its Widgets and Web Services.

You can find the dial-in details on wikis.sun.com.

Project SocialSite (and yours truly) on the LiveMink blog

2008-10-02T16:11:59+00:00

I'm just gonna steal this straight from Simon's blog 'cause I'm lazy.

Simon Phipps: I got the chance to speak with Dave Johnson last week and catch up on his work building Project SocialSite, a social graph framework exposed as widgets and web services for use by websites wanting to build collaborative communities. Both technically interesting and destined to be an important part of the social media scene, I'll be looking forward to seeing SocialSite in action.
[ MP3 | Ogg ]

Social Roller

2008-08-25T19:51:31+00:00

We demonstrated the Project SocialSite widgets in Roller at JavaOne, but we didn't show much other than just the basic widgets. We modified a Roller front-page theme to include a people directory, added a profile page for each user and slapped the widgets on the page. It was pretty rough, as you can see on the right, like our other SocialSite demo vehicles.

This week, I'm working to put together a much better demonstration, something useful enough to deploy to our internal blog site at Sun. Since I have limited time and I really need to get back to working on the SocialSite widgets and web services, I've been thinking about minimum set of features needed to add some value. Here's what I think we need:

Landing page: shows activities of your friends and groups, your inbox of social requests and place for you to update your status. This could be added to Roller's Main Menu page or to pages of the Front Page blog, which is my preferred option.
Personal profile page: shows your mugshot and the subset of your profile information that the viewer is allowed to see. Shows your activities and the OpenSocial gadgets you have installed. This could be done in the pages of each user's blog, which would give folks complete control of profile layout via page templates. Or I could be done in the pages of the Front Page blog.
Activity per entry or comment: whenever you publish a weblog post, or comment on one, an entry will be added to your activity feed so that your friends can see what you're doing. This will be implemented as a feature of a Roller-specific OpenSocial Gadget.
Protected entries: ability to publish blog entries that are visible only to your friends via the Roller Gadget.

Most of the above items should be pretty easy with the SocialSite widgets, but I'm sure I'll run into a snag or two at least. I always do. I'll post again next week and let you know how far I got.

Roller and SocialSite at Open Source Days 2008

2008-08-18T18:36:38+00:00

I'm happy to report that I'll be traveling to Copenhagen, Denmark to talk about Roller and Project SocialSite at the Open Source Days 2008 conference on Oct. 3-4 this year. I'm going to tell the story of Roller and lessons learned along the way and then talk about blogging in the age of social networks and how to social-enable Roller with the SocialSite widgets. The session is called titled The once and future Roller.

re: How the Shindig REST API works

2008-08-11T17:02:15+00:00

Here's a diagram I worked up over the weekend to explain Shindig REST API internals to my team mates. See the Project SocialSite blog for the full story.

Project SocialSite opens up!

2008-08-08T15:36:08+00:00

My teammates and I have started a new blog over at blogs.sun.com to cover Project SocialSite and to break the big news: we're open!

We are very pleased to announce that source code is now available for Project SocialSite (under a CDDL/GPL license) and the project is now operating as an open source project following the Glassfish governance policy. We're working in the open and welcome contributors of all stripes. Read more...

Project SocialSite @ Enterprise 2.0

2008-05-30T13:09:07+00:00

Looks like we made it to the final round of the Enterprise 2.0 LaunchPad competition and so Project SocialSite will be one of the five projects that will "present their ideas in front of an audience of creators, evangelists and adopters of cutting edge technologies who will provide feedback in real-time and decide the winner." Thanks to all who voted for SocialSite.

And in other news, Arun Gupta has put together a very nice ten minute screencast that shows Project SocialSite in action.

OpenSocial summit next week

2008-05-08T19:19:43+00:00

There will be a OpenSocial Summit: May 14th, at the Googleplex covering the new v0.8 spec changes and all sorts of other interesting things. Wish I could make it, but I'll be happily back home in the old north state. Hopefully, somebody from the SocialSite team will be able to attend.

SocialSite on the LaunchPad

2008-05-06T21:36:47+00:00

One more thing to mention before I hit the JavaOne opening reception: Bobby Bissett submitted a short and to-the-point <a href= "http://launchpad.enterprise2conf.com/node/18">video on Project SocialSite to the Enterprise 2.0 LaunchPad. Please check it out and help us vote it up

Getting the word out

2008-05-06T21:36:31+00:00

Jamey Wood and I presented our Introduction to Project SocialSite yesterday. We had a much larger crowd than I expected, given the number of concurrent talks -- I'm guessing there were close to 300 people in the room. I hope to be able to post a link to the slides at some point in the near future because right now we've got almost no information on Project SocialSite on the web. Now that we've got permission to talk about the project, I'm going to try to change that.

I spent most of the day in the Sun booth answering questions about SocialSite and demonstrating our widgets and web services in Roller and MediaWiki and talking through some key slides in our deck. At this point, we only have a handful of our widgets implemented and they're pretty bare bones, but folks seemed to "get it" and liked the idea of adding social networking features to existing web applications.

If you're at JavaOne, then please stop by the Sun both and say hi. Look for us under the banner Social Networking for Glassfish. And if you want the full scoop then check out our Birds of a Feather (BOF) session:

BOF-5857: Turn your website into an OpenSocial container with Project SocialSite
6:30 PM on Thursday
Esplanade 307/310

Jamey and I will be ready with slides and demos and answers to (almost) all of your questions and you'll have plenty of time to make it to the After Dark shindig.

Introducing Project SocialSite

2008-05-04T09:54:18+00:00

As promised, here's some more information about the talk I and my co-speaker Jamey Wood are giving tomorrow at CommunityOne (2:35 PM in Moscone Hall E 135).

Below is the official title and blurb.

Turn your Web Application into an OpenSocial container (link)

Wouldn't it be nice if developers around the world could add new features to your web site for you? The OpenSocial API makes it possible. This session demonstrates how you can make your existing web site capable of hosting OpenSocial applications. To illustrate the process, it shows an example application and how it benefits from becoming an OpenSocial container. Attendees should be familiar with HTML, JavaScriptâ„¢ technology, and XML.

Perhaps a better title would have been, "make your webapps social with Project SocialSite" but we didn't have permission to talk about our project until very recently. Now, we're ready to talk about the Project SocialSite widgets and web services and how you can use them to add Social Networking features to your existing Java, PHP and Ruby webapps. We're not ready to talk about product plans, features or schedules but we are ready to demonstrate our work in Netbeans, MediaWiki, Portal, Roller and possibly some other apps as the JavaOne week progresses.

Here are the slides: socialsite-j1-2008.pdf (1MB PDF file)

And here's an outline of the talk:

Goals
- Understand the importance of Social Networking features in Web applications.
- Learn about the new OpenSocial standard for plugging into Social Networks.
- See how Project SocialSite's Web Services and Widgets make it easy to make your Web Applications social.
Agenda
- Social Software / Web history lesson
- Introducing OpenSocial
- Apache Shindig: the OpenSocial RI
- Options for making your sites social
- Introducing Project SocialSite
- Conclusion and Q&A
Web history lesson
- The static Web
- Blogs, wikis and feeds
- The social Web
- Facebook changes the game
- OpenSocial arrives
- Social Network as platform
- Social networking goes to work
What is OpenSocial?
- OpenSocial architecture example
- The OpenSocial JavaScript API
- The OpenSocial REST API
- Status of OpenSocial
- OpenSocial not the Silver Bullet
- OpenSocial vs. Data Portability
- OpenSocial vs. Web as Social Network
- Is OpenSocial really â€œopenâ€
Apache Shindig (incubating): the OpenSocial RI
- What is Shindig
- Apache Shindig features
- What's missing from Apache Shindig?
How do you make your sites social?
- Plugin to an existing Social Network?
- Use a hosted or â€œwhite-labelâ€ solution?
- Use Apache Shindig?
Introducing Project SocialSite
- Project SocialSite features
- SocialSite Architecture
- Project SocialSite widgets
- Project SocialSite's value adds?
- DEMO: Using the SocialSite widgets
Summary
- For more information: upcoming sessions
- For More Information: helpful links
That's all folks... Q&A

Look for Project SocialSite in the CommunityOne demo area and at the Sun booth in the JavaOne pavillion all week.