[Building Sakai] courier in Sakai 2.9

[Noah Botimer]

I'm pretty disappointed by the quality of information on that "deprecation" ticket: "It has been decided that you shouldn't do what you used to do. Read through the mess on the following link to see this message again, but in color."

The "fix" is likewise disappointing: "This thing is going away, find something else that is better."

If there is a realistic alternative, there should be a link to a write-up, however brief, in Confluence. I acknowledge that the portal chat / new presence have addressed this head-on and have a pretty good solution in place. That's great, but it's insider knowledge and we can't expect someone to make the leap and try to derive a healthy pattern from whatever's implemented there.

If we want to turn JGroups into infrastructure, I suspect there will be some real work to undertake in extracting it from portal chat, including some documentation on how to use it (responsibly) as infrastructure. I think we have the expertise to do all of this pretty easily. If we want to advocate a simple, poll-your-tool pattern, that's even easier to document.

Don't get me wrong -- I'm not disputing the decision to move away from the Courier Service. I just think we can do a better job of communicating with ourselves and the many implementors we don't hear from.

Thanks,
-Noah

On Jan 23, 2013, at 11:07 AM, Matthew Jones wrote:

> Agreed, the way presence was changed was to use jQuery to poll by itself rather than rely on this service (changed in SAK-19129 - revision 82226 specifically). You could convert GAM to poll somewhere to see if there were updates rather than using courier. You don't even need to poll against the same Sakai server.
> 
> I don't remember how GAM worked, but it possibly needed some changes in the portal to pick up the updates. You might be able (as a temporary workaround) turn the old presence updates on with
> display.users.present.iframe=true
> 
> But that would be less than super for performance! (And might not even be in the neoskin?)
> 
> Recent releases of Tomcat 7 support web sockets, so this is seems like the ideal for those on 2.9+ in these situations, and would probably give you much better performance than a polling solution would, especially if you had a lot of things polling.
> 
> 
> 
> On Wed, Jan 23, 2013 at 10:28 AM, Jim Eng <jimeng at umich.edu> wrote:
> Dave,
> 
> The Courier Service was deprecated back in April.  It looks like you are aware of these tickets, but I'll mention them here: 
> 
> https://jira.sakaiproject.org/browse/SAK-22053
> https://jira.sakaiproject.org/browse/GAM-15
> 
> Comments in the code say there are better ways to push messages to the client, but they do not say what the powers-that-be consider a better approach at this point. 
> 
> As I understand it, you are looking for info about how to enable courier deliveries in 2.9 and you will be looking for a better solution for 2.10.   
> 
> Jim
> 
> 
> 
> 
> On Jan 23, 2013, at 9:03 AM, David Haines wrote:
> 
>> At Michigan we're running a contrib tool that relies on courier.  With our upgrade to 2.9 the tool isn't working for us as courier no long runs regularly in 2.9.  Is there a simple way to just turn the courier back on?  In the long run we'll see if find an efficient way to avoid the courier overhead but in the immediate term we need to get this working. While chat in 2.9 uses the courier and keeps it running while the chat is open we can't rely on a single tool to switch the courier on and off.  The tool in question is Global Alerts which needs to be able to send it's broadcast messages to users regardless of the specific tool or site they are using.  
>> 
>> Any ideas are welcome.
>> 
>> Thanks - Dave
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130123/06f0c5b8/attachment.html