Hi Chris,
Question 1: Web Service as Data Store - I would like to build a set of extra modules (somewhat like the guestbook tutorial module) except I expect to access most if not all data via web services. The data lives in a data logger web service and I would like to create modules to access the data and then chart the data using ajax based charts.
You can do anything that is possible with ASP.NET including publishing and consuming web services. However if the web service lives in the same site as the module/feature, I would typically not make it consume a web service because that means you are making a server side web request in addition to serving the page request. It would be better to use business objects directly in your feature and then expose web services based on the same business objects. If you are using ASP.NET 4.0, you could use Entity Framework for the business classes and then easily expose WCF Data service based on the same Entity object(s)
Question 2: Client self registration, then client specific modules separate from other clients - I would like the clients to self register and then configure their own charts. The client config data would exist in the web services, but a pointer between the client logged into Mojo and the client info on the web services would have to be linked.
Can a user self register in mojo?
Can a user register specific features/modules (like my chart module) within their account?
Can the features/modules registered by each user be securely isolated?
A user can register on the site, but mojoPortal was not designed for you to let strangers edit content, editing content requires a lot of trust in the user because it is very easy for someone with edit permissions to enter malicious content such as javascript. mojoPortal is not designed to give users permissions by default, you would have to add the user to roles with more privileges and as I said you should not do that unless you have full trust in the user because they get too much power with most mojoPortal features which allows them to do things that can be good but also can be very bad.
In a custom feature, you can of course expose any functionality you want to users and you can associate it with the user by storing the userid or userguid in your data.
MyPage is based on the ASP.NET WebPart framework which came out in .NET 2.0 but has not really caught on and hardly anyone uses it today. As implemented in mojoPortal, it does not allow users any edit permissions on features. What is does allow is for site editors/admins to expose content instances as webparts so that users can use the content on MyPage. The reason you don't see anything there is because you have not yet made any content available. It is conceptually like iGoogle or MyYahoo or Netvibes where users can personalize pages from available content. For more information see http://www.mojoportal.com/usingmypage.aspx
Hope it helps,
Joe