 | New Concept
|
Information
This page could form a starting point for a Sakai kernel roadmap. For now it is more focused on goals (where we think we want to end up) rather than actions to move us in that direction.
- Information
- Why a roadmap? What is it?
- Possible Kernel Goals
- Back button and navigation that works as expected
- URLs that make sense to users (also called "clean" URLs)
- An accessible portal/tool user interface
- Easy to develop new tools and apps to run in Sakai
- Able to handle 1000 users per app server (with relatively modern specs)
- Easy to install and get up and running in a day
- Reliable and supports High Availability
- Supportable by 1 FTE for a user base of 20000 or less
Why a roadmap? What is it?
A road map should give everyone in the community an idea of what is coming in the future and what the ultimate destination is understood to be (insofar as that is possible). This is meant to focus the efforts of the community and give us a possible method to measure our progress.
Goals may have different scopes like short or long term. Short term goals should be defined in the context of longer term ones (where applicable) and indicate how they will further progress towards long term goals.
Before a roadmap can be adopted there needs to be some sort of review and adoption process. This hasn't happened yet for this document.
Possible Kernel Goals
Please feel free to add your own. Try to avoid mentioning specific solutions as much as possible and instead focus on defining the goals and issues to be addressed.
Back button and navigation that works as expected
- Clicking the browser back button should lead to the page or view that was navigated to just before this page
- Multiple clicks of the back button should allow the user to navigate back multiple pages
- It should not go back multiple pages with a single click of the back button
- It should not cause reloads of submitted data
- It should not cause a "meta refresh" (which will cause the back button to not navigate correctly)
- Usage of web 2.0 (AJAX) should not break the browser back button
- Multiple clicks of the back button should allow the user to navigate back multiple pages
- Hitting back should undo a previous operation as long as the operation was not a post operation
- Post operation here means something where the user submits a form and receives feedback that an operation was performed, this should not be undone by hitting back as this is not how applications on the web tend to work
- The portal should support the use of the back button and should not interfere with the ability for tools to support it as described
- Core tools should support the use of the back button as described
- NOTE: Behavior should be clearly defined by the UX team
- References
URLs that make sense to users (also called "clean" URLs)
- URLs in Sakai should make sense to users and they should adhere to normal web semantics
- URLs should generally be human readable
- The exeption to this is the id which will need to appear in the URL but this id should be as short as possible
- One URL should refer to one resource/document/view/page
- This is a fundamental rule of the world wide web
- URLS should be clean and should not reveal the underlying technology
- URLs should generally be human readable
- Bookmarking a page should create a stored URL which will bring the user back to that page
- This may require the user to login, but after logging in they should proceed to the URL as expected
- Links and GET submissions should be used appropriately (as opposed to POST submissions or redirects)
- Appropriate use would include: viewing an item, searching for items, etc. (basically viewing data)
- Inappropriate use would include: removing an item, modifying an item, adding an item, etc. (basically changing data)
- References
An accessible portal/tool user interface
- The portal and tools in Sakai should be accessible
- Accessibility should be defined by an accessibility expert
- The portal should not use frames or iframes
- Tools should not use frames or iframes and should not assume the are deployed in a frame
- This means tools must be able to operate in a way that does not require frames
- Usage of AJAX/Javascript libraries must not interfere with the portal or other tools
- References
Easy to develop new tools and apps to run in Sakai
- It should be easy for new developers to get started in Sakai
- It should be possible to get a development instance of Sakai working in less than one hour
- Builds should be easy for developers and should be possible with a simple command
- Deployment and undeployment shold be supported by the build program
- New developers should be able to create a "Hello World" in under 30 minutes
- Sakai service APIs should include detailed javadocs and should be intuitive to inexperienced developers
- Intuitive interfaces would have names which make sense and are easy to identify in javadocs
- Service methods should use names for arguments which make the expected value set obvious
- Kernel (core services) should be packaged separately and APIs should be stabilized
- Setting default Authz tool permissions should be simple
- Eliminate the need to hard-code SQL queries that set default tool permissions.
- Support for cross-tool navigation
- Kernel should provide support for tool interactions without requiring dependencies
- Requiring dependencies here means tools should not have to know that each other exist, this especially applies to not having compile/runtime dependencies on the other tool
- Kernel should provide support for navigation between tools without requiring dependencies
- The ability to 'jump' from one tool to another with a simple click on a link in one tool, rather than using the portal navigation.
- Example: in order to change the permissions of the My Workspace of a user, you need to look up the userId in the User-tool, copy it, navigate to the Realm-tool and there you can paste it in the search box "User ID", click "Search" etc... it would be great if it took just one click to navigate to that particular page
- cross-tool navigation for Kernel roadmap contains some further explorations on this subject
A possible solution for this particular case is to develop a 'big' User-tool that will save you many clicks to manage a user
- Kernel should provide support for tool interactions without requiring dependencies
- References
Able to handle 1000 users per app server (with relatively modern specs)
- A single app server should be able to handle 1000 concurrent users
- Modern specs means at least 2 processors over 2GHz and 4 GB of memory
- Usage of threads should be reduced/minimized
- Using Timers for continuously repeating tasks is one way to reduce the thread count
- Database load should be reduced/minimized
- A way to reduce load is to use a high performance cluster wide cache that supports expiration
- Heavy usage of memory should be reduced/minimized
- Caches should all use a centralized cache system
- Storage of user data in session should be removed where possible and reduced/minimized otherwise
- References
Easy to install and get up and running in a day
- Installation should be well-documented, easy, and as automated as possible
- An install which supports 20000 users should be possible in one work day for an admin with no previous Sakai experience
- Unit/Integration tests throughout the framework/kernel code which can easily be run to guarantee system is functioning properly
- Unit tests will ensure independent pieces of code are change tolerant and functioning correctly
- Integration tests will ensure performance/load and allow an easy way to determine if things are setup correctly
- Common enterprise integration approaches should be easily enabled and configured without requiring code changes
- References
Reliable and supports High Availability
- Sakai should be a reliable service and should be able to run continuously
- 5 9's availability should be possible without special setups or configurations
- Server should be stable enough to stay up over long periods without requiring restarts
- If servers do go down then they should be able to do so in a way that is transparent to the user (failover)
- Session duplication/sharing might be a solution to allowing server restarts/failures without disruption
- Kernel codebase should include automated testing to ensure stability and reliability of code
- All kernel components should have unit testing with at least 50% overall code coverage
- Function covereage should be at least 90%
- Unit testing should always run during Sakai compiliation
- Optional load/integration/validation testing should be easy (and possible) to run
- Load testing ensures performance is not degrading
- Integration testing ensures components are operating together correctly
- Validation testing ensures the data in a system is valid (useful to run after upgrades)
- Ideally this testing would be verfied, validated, and heavily used by the QA team
- All kernel components should have unit testing with at least 50% overall code coverage
- Kernel code quality should be protected and insured via a set of best practices
- Use of branches to make changes to kernel code should be required
- Global commit access should be restricted to branch managers
- References
- http://en.wikipedia.org/wiki/High-availability_cluster
- Test Runner
- Best Practices for Kernel code
- Best Practices for Kernel Updates
- http://en.wikipedia.org/wiki/Software_testing
- http://en.wikipedia.org/wiki/Code_coverage
- http://en.wikipedia.org/wiki/Test_automation
- http://en.wikipedia.org/wiki/Unit_testing
- http://en.wikipedia.org/wiki/Integration_testing
- http://en.wikipedia.org/wiki/Software_performance_testing
Supportable by 1 FTE for a user base of 20000 or less
- It should be possible to administrate and support Sakai with only 1 full time (experienced) administrator
- Continuous maintenance tasks should be removed/minimized
- Scripts and administrative tools should support necessary admin activities
- Server should be able to undeploy and redeploy webapps and components without restarting
- Component Manager should support the ability to redeploy core parts of the system
- Server should be able to run continuously without needs for restarts
- Sakai should support the ability to do (minor) upgrades/patches without downtime (if there are multiple nodes in the cluster)
- Data validity should be protected by the system
- Logically atomic operations should be wrapped in atomic transactions
- Spring transaction management might be option here
- Data should be readable by system operators in the storage medium
- Example: Store strings so they are readable and editable and not as encoded xml or binary data
- Example: Store the value ("student") rather than a number or code ("1")
- Logically atomic operations should be wrapped in atomic transactions
- Configuration should be well documented and easy to use
- All kernel services should be configurable without editing code or maintaining local patches
- Kernel services should have providers and plugin points to make extension and customization easy
- Common plugin points should be easily extendable without instiutions maintaining local patches
- Providers should be supported in all common plugin points
- References
Comments (26)
Oct 06, 2007
Hannah Reeves says:
Thanks for initiating this Aaron. The idea of a public roadmap makes a great dea...Thanks for initiating this Aaron. The idea of a public roadmap makes a great deal of sense.
I hope we can spend some time discussing it at the planning meeting in Newport Beach.
Oct 07, 2007
Mara Hancock says:
This looks really good. I like that is is high level goals and that it addresses...This looks really good. I like that is is high level goals and that it addresses some core usability issues – including key performance goals. I am certain it gets more complicated the deeper beneath the surface we dig, but having the goals agreed upon is the first step. I am +1 on all these framework goals.
Oct 08, 2007
Mark J. Norton says:
> It should not go back multiple pages I don't understand this one. Why shouldn...> It should not go back multiple pages
I don't understand this one. Why shouldn't an application go back multiple pages? If I press the back button, isn't it reasonable to assume that I can go "back" from there? If the application is stateless, or manages undo properly, going back multiple pages is no harder than going back one.
Oct 08, 2007
Aaron Zeckoski says:
I clarified the wording to express this more clearly. I meant, you should not go...I clarified the wording to express this more clearly. I meant, you should not go back multiple pages with a single click of the back button but should always go to the previous view.
Oct 09, 2007
Mark J. Norton says:
Thank you for the clafication. Once click per page back is just fine.Thank you for the clafication. Once click per page back is just fine.
Oct 08, 2007
Michael Korcuska says:
I think what he means is that a single click only goes back one page. From there...I think what he means is that a single click only goes back one page. From there, I assume, you go can go back again.
Oct 08, 2007
Michael Korcuska says:
Aaron, Very nice start. I think you should add "Framework" or "Kernel" to the t...Aaron,
Very nice start. I think you should add "Framework" or "Kernel" to the title. I don't think you're meaning a full Sakai roadmap....
Oct 08, 2007
Aaron Zeckoski says:
These goals are very high level ones. I mean, they would certainly apply to the ...These goals are very high level ones. I mean, they would certainly apply to the kernel or framework (once that is defined) but I would think they should probably apply to whatever we consider to be "Sakai", whether that is the product or the community or both or something else entirely. Since that adds to confusion here I will change the name.
Oct 09, 2007
Mark J. Norton says:
I agree with Aaron. These are very high level goals and have pervasive impact on...I agree with Aaron. These are very high level goals and have pervasive impact on all of Sakai. That said, there may be other things that can be included in this road map that are not tightly associated with kernel changes. For example, a new release process with phased implementation might be included.
Oct 08, 2007
Stephen Marquard says:
I think "not go back multiple pages" means "don't skip pages", i.e. go back to t...I think "not go back multiple pages" means "don't skip pages", i.e. go back to the page just before this one.
Oct 08, 2007
Aaron Zeckoski says:
I'm having some trouble understanding how the material that follows (the list of...I'm having some trouble understanding how the material that follows (the list of goals) is a roadmap given the above definition (of a roadmap). While I agree with all of the goals that follow, they read like a grand unified feild theory for Sakai – clearly desired, not achievable in the next six to twelve months. To me, a road map should talk about the immediate steps needed to reach these goals. The goals themselves should be encapsulated into high level goal documents or requirements.
– Mark Norton
-AZ
Oct 09, 2007
Mark J. Norton says:
Ok, I'll keep comments at the bottom and not inline. :) Makes it easier to read....Ok, I'll keep comments at the bottom and not in-line.
Makes it easier to read.
I added a few lines to the roadmap definition that addresses my concern – that of near term and far term goals. While having long term (ie, major) goals is important, it's the near term items that keep us focused. Saying "we need the back button to work" hasn't gotten us any closer to making it work over the past three years. We need incremental movement (near term goals) towards the larger goal.
Also in this section, there is a statement, "there needs to be some sort of review and adoption process". I agree in principle, but I also have a concern about this. Would not formal review and adoption signal commitment to the Sakai community with respect to those goal/items? Commitment is a good thing, but in truth, it only sets us up for failure.
Oct 10, 2007
Colin Clark says:
Aaron, this is a very good starting point for a framework roadmap. It represents...Aaron, this is a very good starting point for a framework roadmap. It represents a clear picture of how the underlying Sakai technology should enable a better user experience by supporting 1) a viable back button; 2) stable, bookmarkable URLs (I think these qualities are far more important to the user than having them "make sense", though it's a worthwhile goal); and 3) an better portal that doesn't depend on the use of perplexing and inaccessible iFrames.
I made one little change. In the portal section, I added a link to the checklist I've been working on for DHTML developers outlining best practices for portal friendliness and accessibility.
Oct 10, 2007
Colin Clark says:
Another thought. Should the roadmap include a goal for testability and broad uni...Another thought. Should the roadmap include a goal for testability and broad unit test coverage? It seems to me that one of the things that will make the framework more reliable and performant is better code-level testing.
Or perhaps testing is a means to the ends outlined in this document?
Oct 11, 2007
Aaron Zeckoski says:
Good point. I think you are right in thinking testing is a means to an end here....Good point. I think you are right in thinking testing is a means to an end here. However, I mentioned it as a subpart where it is likely to have the largest impact. I think testing does make sense and I think everyone realizes it is part of the overall quality process so it is somewhat implicit in most of this roadmap.
Nov 01, 2007
Michael Korcuska says:
Aaron's edits to the Dev home page are the projects/proposals that should suppor...Aaron's edits to the Dev home page are the projects/proposals that should support the goals outlined here. I think adding explicit references to those pages about what goals they support and links from the goals to the projects that are underway would be great.
And developing unit testing standards/recommendations would be a great project in support of many of these goals.
Nov 02, 2007
Aaron Zeckoski says:
Makes sense to me, I added in some testing recommendations under the section tha...Makes sense to me, I added in some testing recommendations under the section that talks about testing. I will link in the best practices and kernel practices documents as well as both of those proposals talk about including testing.
Oct 18, 2007
David Haines says:
What does Framework refer to here? Is it the minimal Sakai configuration related...What does Framework refer to here? Is it the minimal Sakai configuration related to the Sakai Kernel? Is it the more general set of conventions that all Sakai tools should conform to?
Oct 18, 2007
Aaron Zeckoski says:
From my perspective these are goals we want to achieve in Sakai in general. Howe...From my perspective these are goals we want to achieve in Sakai in general. However, to keep things simple I figured it was best to limit the scope to just the framework/kernel for now. That said, nothing here is meant to be a prescriptive convention that a tool writer must conform to and nothing says it has to only apply to the kernel.
Oct 22, 2007
Raad Al-Rawi says:
I think we should mention interoperability / integration / interfacing somewhere...I think we should mention inter-operability / integration / interfacing somewhere. I'm not an expert in these areas of Sakai, but I'm sure there must be web services/integration standards that Sakai does/intends to support.
Nov 01, 2007
Michael Korcuska says:
Aaron, I've been thinking your "Supportable by 1 FTE" might be better split into...Aaron, I've been thinking your "Supportable by 1 FTE" might be better split into two goals. One would be "Supportable by 1 FTE" and the other would be "High Availability (5 9s, or at least 3)". The criteria underneath are the most important thing, though, so I don't feel strongly about it.
Nov 02, 2007
Aaron Zeckoski says:
I like the idea. It sorta makes sense and splits out the concepts of "reliable" ...I like the idea. It sorta makes sense and splits out the concepts of "reliable" and "supportable". I have made this change and added details to both areas.
Nov 04, 2007
Mark J. Norton says:
If the "kernel" doesn't include tools (and hence no UI), why does this roadmap i...If the "kernel" doesn't include tools (and hence no UI), why does this roadmap include so many UI related issues? Personally, I envision the kernel as the the low-level services that support tools.
Nov 05, 2007
Aaron Zeckoski says:
The kernel does include the portal which is what many of the UX issues are refer...The kernel does include the portal which is what many of the UX issues are referring to. It also includes tool support code (e.g. which tool am I accessing now, etc.) so some of the issues touch that area. It will probably also include at least one tool as an example of best practices or to support the services themselves (this has not been decided yet).
I think the UX goals are some of the most critical goals here and even though this is meant to affect the kernel only, I hope that these will be looked at as goals that all Sakai tools should also strive to adhere to.
We may want to look at renaming this to framework goals if that makes people happier.
Nov 05, 2007
Mark J. Norton says:
Personally, I think the kernel (ie, framework) should be completely UIfree. Not ...Personally, I think the kernel (ie, framework) should be completely UI-free. Not that I don't agree with you that there are many critical UI problems to be addressed, but separation of presentation/UI from business and support logic is fundamental to the Sakai architecture going back to the very beginning of Sakai. Adding in UI and UX issues distracts us from the main focus of the kernel services:
1. Good factorization
2. Separation of concerns
3. Integration strategies that allow for modularity and minimal dependencies
4. Scalability and performance.
Dec 02, 2007
Michael Korcuska says:
Possible crosssakai functional goals that might impact the kernel: 1. Consisten...Possible cross-sakai functional goals that might impact the kernel:
1. Consistent and flexible group management
2. Goal awareness
3. Archiving and importing