The NEW Federated Access Manager 8.0 Developer's Guide

I am the writer assigned to the Sun Java System Federated Access Manager 8.0 Developer's Guide. This tome will be released with the product in 2008. I predict a multitude of changes between the Access Manager 7.1 Developer's Guide and this new Developer's Guide. I have sent out a link to this blog entry because I'd like to solicit feedback from customers and the field as I am ramping up my documentation plan. I already have some of my own ideas but this is the perfect time to have your voice heard.

If you have any ideas on how I can improve the Developer's Guide, please comment me. I appreciate any input.

When you see the new Developer's Guide in 2008, you'll be as happy as...um...as happy as...hmmm...as happy as...oh! A dog and his ball.

Max and his tennis ball, that is.
Comments:

A migration guide from the depreciated API's of the AMSDK/AMClientSDK would be good. E.g com.iplanet.am.sdk

Posted by Mark de Reeper on November 12, 2007 at 01:21 AM PST #

#1 A unit test framework to sanity check your install, with predetermined tests - hopefully a selection/all that QA/testing already use.
#2 A fast-track, one command (a) command line build (b) container deployment, to provide a selection of (the same) working samples. I've facilitated many clients that got completely stuck in the deployment and configuration of the simplest testcode/samples - without even getting to the actual development. This often entails me building a custom SDK delta for my clients, and that of course has ramifications.
#3 As your document progresses grab some green, but competent Java developers, put them in a room, see how fast they make the samples work, document what went wrong.

Posted by mark davis @ sun on November 12, 2007 at 01:58 AM PST #

Two excellent comments. Question about #2 in the second comment, is that something that can be done in the doc? It sounds more like development. Can you elaborate? Thanks.

Posted by DocTeger on November 13, 2007 at 12:02 AM PST #

Re #2, I rarely give feedback, so I took the opportunity to get the comment out there ;-) so I hope others are reading
#3 Would facilitate the capture of environmental dependencies/gotchas that can occur.
From a documentation perspective, I'd encourage a command line java test, then an appserver test with the same functionality - that is, start simple then add complexity, I see many who try to go the other way round.

Posted by mark davis @ sun on November 15, 2007 at 03:40 PM PST #

# policy collision logic
Describe policy collision logic thoroughly, that is, multiple policies, multiple conditions (such as two or more time ranges), and work an evaluation through. People would then know the limits or logic exceptions, and potential work arounds.

Posted by mark davis @ sun on November 26, 2007 at 04:25 PM PST #

I've never even heard that term before. (FYI, I searched it and all I got was car insurance.) I understand what you mean though and I put it in my doc plan. Thanks.

Posted by DocTeger on November 26, 2007 at 10:30 PM PST #

How exactly can we get a copy of this new developer's guide?

Posted by ppetit on November 27, 2007 at 05:28 PM PST #

The guide is being written now. I am currently working on the client SDK chapter. I will post links for review here as I finish each section.

Posted by DocTeger on November 27, 2007 at 10:42 PM PST #

Post a Comment:
Comments are closed for this entry.
About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today