[Building Sakai] courier in Sakai 2.9

[Matthew Jones]

>From what I remember with the discussion (it was long ago) it was either
get people to support the tool and fix the problems with it or mark it as
deprecated and work on removing it for 2.10. Presence (the primary user)
already no longer used it in 2.9 and I *believe* someone was working on
changing the chat delivery.

I suppose if you have a tool that relied on portal scripts for presence
making request to courier for your tool to function in 2.9, that was
something we couldn't test in core. Very likely it was *only* the Global
Messaging Tool. Chat still takes care of courier message delivery itself.


On Wed, Jan 23, 2013 at 11:31 AM, Noah Botimer <botimer at umich.edu> wrote:

> 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/a038b843/attachment.html