[sakai2-tcc] Annotation based injection within Sakai components

[John Bush]

I think we'd be better served steering this conversation back to
chucks list, as I think he approach is the better.  The discussion
about where to move sakai should start at a tactical/strategical
level, not at a technology/development level.

Our problems right now are not really mostly in the development
tooling area.  The biggest roadblocks for Sakai are operational.  It
is big and complicated and hard to deploy and manage.  Things like
multi-tenancy, messaging, and performance in authz, lowering the
memory footprint (velocity state refactor) address those issues.

I'm sorry I said "pain in the ass", I think it is, you can disagree.
It not really helpful you are right.

So can we talk about the tactical things, I think Chuck has the right
list to start with.  Technology decisions should fall out from that, I
think we are starting this whole discussion upside down.

On Wed, May 16, 2012 at 9:15 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> For the benefit of those of us with the "curse of knowledge". I would
> love a list of how these other systems are easier to get started with
> and develop from someone who is newer to Sakai development. I don't
> find the "Sakai development sucks" and "X development is awesome"
> comments helpful at all without details.
>
> I do like the plugin style development in Moodle, Drupal, Wordpress,
> Blackboard, etc. Being able to upload a chunk of code as a plugin is
> nice for sure but I don't find it really speeds up my development that
> much. I typically just edit my code right on the wordpress or
> blackboard instance rather than re-uploading the plugins over and over
> so that's really more of an admin benefit IMO.
> The really dev benefit tends to be the support in the platform that
> makes it easy to control versioning (DB updates, migrations, etc.) and
> built in support for plugin configuration and things like that.
> I think that stuff could be built for Sakai but I question the ROI
> (and especially the opportunity cost) at this point in time.
>
> -AZ
>
>
> On Wed, May 16, 2012 at 11:48 AM, Matthew Jones <matthew at longsight.com> wrote:
>> Well, how long does it take a new developer who has never used Sakai
>> Services before to write a new tool that integrates with
>> assignment/gradebook/assessments/calendar/entitybroker.
>>
>> My guess would easily be months. So this makes/keeps the development pool
>> for Sakai small (a fixed ~10-15 devs?)
>>
>> How long does it take someone to write a new tool for any service with an
>> external API? Lets take for example Pivotal Tracker or Harvest (because I've
>> written full new tools against those) . . . About a day or two to learn it,
>> and two weeks tops to have the app (or wordpress/drupal module)
>> fully functional, polished and in production.
>>
>> And that doesn't even mention the long term maintenance costs of a tool
>> after the original developer leaves and no longer supports it.
>>
>> Perhaps there are plenty of tools, but most of the ones used in core have
>> been there in maintenance mode since 2007/2008, and most of the
>> ones outside of core (contrib) were written by this limited group of
>> developers over the last few years.
>>
>> For Sakai, I guess plenty of tools = 50. For Moodle its near 500.
>>
>> Sure quantity doesn't equal quality but the new user learning curve is
>> pretty steep, and the reload time of tomcat is annoying.
>>
>> On Wed, May 16, 2012 at 11:26 AM, Adrian Fish <a.fish at lancaster.ac.uk>
>> wrote:
>>>
>>> Can you tell us why you think CLE coding is a pain in the arse? The
>>> 'fact' of it being a 'pain in the ass' doesn't seem to have deterred
>>> people from writing plenty of tools for it ...
>>>
>>> Cheers,
>>> Adrian.
>>>
>>> On 16/05/2012 15:22, John Bush wrote:
>>> > well right.  I guess what I'm saying is a reaction to matthews email.
>>> > Little incremental changes like moving to this version of spring or
>>> > that version of whatever aren't any sort of game changer for Sakai,
>>> > they aren't going to solve the fundmental problems.  So if those
>>> > incremental changes lead to a bunch of problems for no real gain, I
>>> > don't see the point, it seems like a giant waste of effort.
>>> >
>>> > The fact that its a giant pain in the ass to do Sakai development
>>> > isn't going to be solved by these little things.  Its still going to
>>> > be a giant pain in the ass.  Maybe a little better, but still way too
>>> > hard.
>>> >
>>> > I can't see why anyone would even want to build a new tool in sakai at
>>> > this point, at least if you believe OAE will get off the ground at
>>> > some point.  LTI makes much more sense, since anything you do there
>>> > can run in OAE when its ready.
>>> >
>>> > That said I don't object to a kernel 2.0, it can go off and do its own
>>> > little thing.  But I'm very doubtful that it would have much adoption
>>> > at this point, outside of a few places, so in reality I'm not worried
>>> > about it breaking anything, because I don't think anyone will even use
>>> > it.
>>
>>
>> _______________________________________________
>> 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