[Building Sakai] Using reflection to improve compatibility (was 2.9 Ideas: Include Mailsender in Sakai core?)

[Adrian Fish]

Not trying to hijack this thread but ...

One of the concerns raised about neochat for 2.9 at the TCC meeting in 
LA was the use of reflection to detect the installation of Profile2. The 
android link provided by Matthew espouses this approach to improve 
backwards compatibility. It's exactly what I do in the portal chat 
service code and I reckon it could be used lot more broadly in the Sakai 
code base.

Just my 20p.

Cheers,
Adrian.

On 19/06/2011 23:00, Matthew Jones wrote:
> Comments inline!
>
> On Sun, Jun 19, 2011 at 1:59 PM, Carl Hall<carl at hallwaytech.com>  wrote:
>> On Thu, Jun 16, 2011 at 2:16 PM, David Adams<da1 at vt.edu>  wrote:
>>
>>> Currently, Mailsender does not use the Sakai EmailService to send mail,
>>> but rather re-implements the service itself.
>> . . .
>> Given these, Seth and I made an executive decision in Denver last year to
>> drop support for the central email service and to review this at a later
>> time. As stated in MSND-35, that time has come.
>>
> We really should have a better policy (specifically for contrib tools) on
> how to handle compatibility issues. The best way I've found is either to use
> wrappers which are only activated by specific maven profiles (sakai-2.7,
> sakai-2.8) or by using reflection. This is extra work for the tool developer
> but much less than maintaining multiple versions of the code. This is
> usually the suggestions made for Android Backward compatibility guide.  [1]
>
> Sometimes this isn't always possible, like if you need to extend interfaces
> or if new methods are added, or if you need serious performance, but I think
> for the vast majority of compatibility problems we (Sakai in general) should
> have a better guidelines and make it easier developers not to worry about
> this. Usually the api is pretty backward compatible to begin with and you
> only have to "add" to it, like in this case, if you need something that
> isn't there. This *can* be done with the build-helper-maven-plugin or
> careful packaging of dependencies and profiles, but I don't know how well
> this is documented.
>
> I also believe as external api's (like entitybroker and webservices) get
> more fleshed out, we'll eventually have to start versioning these and
> providing some type of built-in backward compatibility. We can't rely on
> having to have every external application which connects to these to upgrade
> at the exact same time as the main system upgrades, and we also can't keep
> old api's upgraded forever. For example, google has depreciated maps api V2
> and is no longer supporting V1.  I think we should at *least* have a 2.7 API
> that still *works* when someone is running a 2.8 instance. Anyway something
> to think about. ;)
>
> I also agree with Carl's other comments. Michigan has been running
> mailsender instead of mailtool for years now without any issue. If there was
> a blocker or critical and wasn't getting addressed, we would fix it. I think
> a strong +1 for inclusion in any tool into the core is "how many places with
> developers on staff are running this tool as part of their core
> distribution". Many projects don't appear to have too much activity, but if
> they are running somewhere where there are developers I'm sure any serious
> issues are at least getting maintained though maybe not any more features as
> Carl said. ;)
>
> [1]
> http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
>
>
>
> _______________________________________________
> 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"

-- 
==================================
Adrian Fish
Software Engineer
Centre for e-Science
Bowland Tower South C Floor
Lancaster University
Lancaster
LA1 4YW
email: a.fish at lancaster.ac.uk

http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/CLOG/Home
http://confluence.sakaiproject.org/display/BBB/Home

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110620/3794f8df/attachment.html