[sakai2-tcc] Annotation based injection within Sakai components

[Matthew Jones]

On Thu, May 17, 2012 at 9:37 AM, Adams, David <da1 at vt.edu> wrote:

> Matthew Jones wrote:
> > [re session state transferability] This isn't even a problem users notice
>
> Well, they notice when an app server crashes and they lose their work or
> get signed out entirely. And they notice that code updates require outage
> windows of at least 15 minutes (you can sometimes do rolling upgrades, but
> unless you're doing it over the course of hours, there will be a period of
> time where users will experience unreliability).


I guess depending on how your system is setup and what the student was
doing could make it more noticeable for sure. If you have a single sign-on
and a server crashes, unless someone is involved in a workflow of a tool
with state they might not notice at all. The big problem would obviously be
tools with long complex work-flows like Samigo (if you didn't have autoSave
enabled) or possibly any text editor (where we don't have
any possibility currently for autosave outside of OSP). I typically run
with client side plugins like lazarus because I expect my browser is more
likely (and often does) to crash more often than any server. Though for
sure I agree that the problem is more in general that students have a
chance of losing their work if the client or server goes down. And there
are some tools where if this happens and they're not running lazarus it's
more disastrous than others.

Great point. Users are right to expect our webapp not to break their web
> browser. Being able to open multiple tabs easily was a huge leap forward in
> browser functionality, and it's incredibly frustrating to users when they
> run into the problems caused by this feature being broken. Is it an
> inherent problem of JSF or is there not some way to work around it? It
> appears to me (not a developer) that for most JSF tools, Sakai provides
> JSF, so is there no way to correct (or at least get closer) through some
> global configuration or code changes in the JSF project?
>

No, this isn't about JSF by itself, this is also a problem with velocity
tools as well. I believe it's mostly about how the tools kept everything
about the state of the workflow in the users session, and multiple tabs
still were the same session. It seems like you'd either have to store this
state client side, (I think with JSF you can even flip a switch and have it
store client side) and that has pros/cons, or somehow treat each new page
separately. Not sure the "how" on this, maybe embedding unique page/tab ids
on every form or adding more junk to the url. Would be some work, not sure
how that would impact the server session size. But should make stuff work
better.

I'd estimate that a large percentage of user problems that get escalated to
> my (operations/log/db troubleshooting) level are related to this failure.
> And I expect there are 10 times as many users who don't report, but just
> chalk it up to the flakiness they've grown accustomed to. We're talking
> dozens or hundreds of such issues, many minor, each week. I think fixing it
> would be a huge benefit, though if fixing it means rewriting every single
> JSF tool with some other presentation layer, perhaps not.
>

Yea, it might mean rewriting every tool at this point with the initial
design goals of preferring stateless system. This is convenient for a
completely REST based service. . . Which probably isn't in the cards for
the CLE, as so many internal methods require that some things are already
set.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120517/a892b276/attachment-0001.html