[sakai2-tcc] Annotation based injection within Sakai components

Matthew Jones matthew at longsight.com
Wed May 16 08:48:41 PDT 2012


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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120516/01ec8216/attachment.html 


More information about the sakai2-tcc mailing list