[sakai2-tcc] Infrastructure discussion for future meeting?

Wed Mar 13 16:23:29 PDT 2013

So now that we got that all behind us, I've honed in on apollo mq for
a number of reasons.

1.  You can run it embedded (making the last really fun discussion irrelevant)
2.  Its faster than everything else b/c it has a non blocking IO
paradigm (like node.js),
http://hiramchirino.com/stomp-benchmark/ec2-c1.xlarge/index.html
3.  It has a JSON based rest api for admin, not JMX (puke)
4.  Language independent options: STOMP, AMQP, web sockets
5.  It can do a web socket transport:  awesome for the front end use
cases, no more javascript polling.  For things like chat, long lived
processed, etc would be really easy and slick
6.  Its written in Scala, I'm on a scala kick recently.  It just a
great pair for the non blocking io, scala functional components handle
those sorts of callback really well.

#6 is just for me, but I think the rest are on target in general.

I'll start kicking the tires around and report back, I bet it wouldn't
be too hard to replace the old messageservice code in contrib with
something like this.  Then we could talk about some new capabilities
we'd want to expose on top of it.

On Wed, Mar 13, 2013 at 3:18 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> On Wed, Mar 13, 2013 at 6:05 PM, John Bush <john.bush at rsmart.com> wrote:
>> forward ?  Maybe we are better served by having an architecture that
>> actually supports the big guys, the big guys whoever they are bring
>> more resources to the table in the end, and that is the path towards
>> sustainability.
>
> It's not either-or here. We don't have to give up LDAP support to
> allow CAS or give up local users to allow kerberos. We don't have to
> give up external message processing to have internal message
> processing either.
>
> As for Moodle vs Sakai vs Canvas... I deal with a lot of RFPs which
> treat them as generally interchangeable. I won't debate that in any
> way but clearly there is a perception somewhere out there in the
> industry we are part. Considering the "usual suspects" that most
> institutions look at when choosing a campus LMS I think it is pretty
> clear we operate in a similar space. Probably more like a venn diagram
> than a single circle but there is a lot of overlap. Besides, why make
> the evaluation stage hard when it is not necessary?
>
>
>> Second, deployment and configuration tooling is nothing like what is
>> used to be.  Puppet, chef, capistrano, vagrant, the list goes on and
>
> Yes, I have heard this argument many time over the years and yet, here
> we are today still mostly installing Sakai step by step. If it is so
> easy then why hasn't anyone done it for Sakai? Prove me wrong and put
> together a nice cross platform installer that works in the cloud and
> locally. You'll shut me up and make lots of people happy all at once
> (including me).
>
>
>> But again, I'm not suggesting we move to requiring more than one
>> server, I just like to argue with you.
>
> Oh goody.
>
> -AZ
>
>
>> On Wed, Mar 13, 2013 at 2:32 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>> future.  What if only certain things didn't work in a one jvm/tomcat
>>>> demo world, that be consistent with how things are now.   I mean
>>>> things like ldap don't work ootb right now without an ldap server
>>>> living somewhere.
>>>
>>> Yes, but users can still login without LDAP because there is local
>>> user management support included. Obviously LDAP or AD or something
>>> like that is a more scalable and enterprise option but we don't fail
>>> to run if there is no LDAP server.
>>>
>>> I am all for having a modular system with swappable parts. You won't
>>> be able to use a classroom clicker with Sakai without some external
>>> system and hardware. That's fine. But requiring an extra server just
>>> to run it is not comparable to that situation. For example, I don't
>>> think Moodle would adopt something that meant you needed to run tomcat
>>> or a ruby server alongside your PHP webserver. I don't think I am
>>> "thinking inside the box" or "stuck in the past" or "not thinking
>>> about current tech" here. This is an app that people need to install
>>> on multiple platforms and the harder we make that for them and
>>> ourselves the less successful we will be.
>>>
>>> I think this discussion (deciding that Sakai will no longer run in a
>>> single JVM) is a huge one and needs a new thread.
>>>
>>> It is also nowhere near being a low hanging fruit issue like some of
>>> the others on the list that don't require changing the way users
>>> install and run the software.
>>>
>>> -AZ
>>>
>>>
>>> On Wed, Mar 13, 2013 at 4:12 PM, John Bush <john.bush at rsmart.com> wrote:
>>>> I think David is asking why is that the requirement ?  We shouldn't be
>>>> letting our demo dictate our platform.  Maybe that not the compelling
>>>> reason, but then if not one only one process?  What makes that a
>>>> non-starter ?  I understand this has been our position in the past but
>>>> what is the reason we need to work towards that necessarily into the
>>>> future.  What if only certain things didn't work in a one jvm/tomcat
>>>> demo world, that be consistent with how things are now.   I mean
>>>> things like ldap don't work ootb right now without an ldap server
>>>> living somewhere.
>>>>
>>>> On Wed, Mar 13, 2013 at 12:57 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>> I mean it should run in one JVM and tomcat. I don't think I can add
>>>>> much to that.
>>>>> -AZ
>>>>>
>>>>>
>>>>> On Wed, Mar 13, 2013 at 3:47 PM, David Adams <da1 at vt.edu> wrote:
>>>>>>
>>>>>> Aaron Zeckoski wrote:
>>>>>>> Mostly I mean running in the same tomcat (think the Sakai demo).
>>>>>>> If it won't work as part of the Sakai binary/demo then that's a
>>>>>>> non-starter IMO.
>>>>>>
>>>>>> Could you explain more what the issues with this would be? Is there a
>>>>>> reason why the demo/binary couldn't start up and manage two processes
>>>>>> just as well as it does one?
>>>>>>
>>>>>> -dave
>>>>>> _______________________________________________
>>>>>> sakai2-tcc mailing list
>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>
>>>>
>>>>
>>>> --
>>>> John Bush
>>>> 602-490-0470
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

--
John Bush
602-490-0470