[Building Sakai] cleaning up the Sakai web services

[Noah Botimer]

Steve,

This sounds reasonable but I do want to make a finer point.

Consider an institution with a single admin/hacker running Sakai and  
100 other things as admin/hackers often do. He doesn't have a  
replicated environment for testing. He often makes riskier moves than  
the large, very experienced shops, working on live wires occasionally  
because of resource constraints. He has some scripts he runs when  
certain kinds of requests come in, to create a site a special way,  
add a list of people (he hasn't implemented a Group Provider), and  
who knows what else. His scripts point at the production instance and  
he tests them in production sample sites. Mostly he's "just fine" and  
"surviving".

Now, consider the same admin in two situations:

   1. Part of some version upgrade is "Update your scripts to point  
here, there, and the other. Call this method differently. The  
signature for addFoo() now includes one more parameter."

   2. Part of some version upgrade is "You should now call these  
things differently because they're going to go away in the next  
version."

My point is that, in situation one (as you suggest), the system  
upgrade and the script upgrades are coupled. He can't port web  
service consumers while the system is running and test them live. He  
has to build this into the (functional) downtime for the upgrade in a  
big bang transition. Sure, he could go pull stuff from trunk and drop  
it in, but he's not sure of what all changed or if there is a subtle  
service dependency difference. Frankly, he doesn't have time to track  
it down and run experiments.

In scenario two, he reads the first version notes and says, "OK. I'll  
have to work on moving those over. I'll probably do it in the last  
two weeks before the next upgrade with the system live and I'll get  
the kinks worked out then.". Because this is a technical deprecation  
where the layers move asynchronously, he can inch forward in  
preparation, and have confidence that he's ready before the second  
upgrade is in the moment.

I'm sorry to belabor this, but we should strive to make work we do on  
Sakai 2.x push maintenance costs down. Synchronized, coupled  
conversions raise costs and make upgrading harder. I'm not going to  
try to say "no, you can't do that", but I will ask you to consider  
this and will trust your judgment. You are, after all, doing the work.

Thanks,
-Noah

On Mar 6, 2010, at 8:12 PM, Steve Swinsburg wrote:

> Hi Noah,
>
> The plan was to mark anything I don't receive information about as  
> deprecated, and update them to add some logging about them being  
> deprecated (maybe even include this logging in 2.7 to give adequate  
> notice).
>
> Then, at some point in the 2.8 cycle, move them into an 'archived'  
> or 'deprecated' directory. Services that are being used would be  
> migrated and documented and implementors would have quite some time  
> to update their applications to look at the new location (from now  
> until 2.8.0).
>
> So it would be two upgrades away (2.8.0).
>
> cheers,
> Steve
>
>
>
>
>
>
>
>
> On 07/03/2010, at 3:50 AM, Noah Botimer wrote:
>
>> Hi Steve,
>>
>> I think it's great that you're looking to take inventory and give  
>> a single, consistent place for people to look.
>>
>> However; I have to urge that nothing be moved/removed in one shot.  
>> These are part of an external contract that people write their  
>> tools and scripts against. Copying methods and marking the  
>> originals as deprecated with a full cycle to port would be fine.  
>> Making the very next upgrade contingent on porting stuff for  
>> cleanliness is probably too far, causing unnecessary admin/ 
>> development stress. If I can port things a la carte over a whole  
>> generation, I'm much happier.
>>
>> An important point here is that there are no internal consumers of  
>> these services where we need to make exclusive changes for a fix,  
>> enhancement, or refactoring. And we can't find/test the consumers.  
>> I suppose I might say "it ain't broke; improve it but don't break  
>> it".
>>
>> SakaiSigning is definitely used for verification of LinkTool  
>> launches. See linktool.txt in the top level of the module source.
>>
>> Your interest and energy here are much appreciated.
>>
>> Thanks,
>> -Noah
>>
>> On Mar 6, 2010, at 8:46 AM, Steve Swinsburg  
>> <steve.swinsburg at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am looking to cleanup and consolidate the current suite of web  
>>> services, but have a few queries about some of the JWS files that  
>>> are in there.
>>>
>>> The main web service sets are:
>>>
>>> SakaiLogin - remote login/logout functionality
>>> SakaiScript - the main set of administrative functions
>>> Portfolio - portfolio functions
>>>
>>> However, there are a number of others which are undocumented and  
>>> sometimes duplicate existing functionality in the main ones  
>>> above.  In particular, I would like some information about the  
>>> following:
>>>
>>> SakaiPortalLogin.jws
>>> SakaiSession.jws
>>> SakaiSigning.jws - I believe this is used by the LinkTool, but in  
>>> what capacity? I can't find any working reference to it in the code.
>>> SakaiSite.jws
>>> WSContent.jws
>>> WSSession.jws
>>>
>>> Are these being used? It seems reasonable that the functionality  
>>> from these could be rolled into either SakaiLogin or SakaiScript,  
>>> which will make maintenance and testing easier, and might bring  
>>> some useful functionality to the general population, or remove  
>>> them entirely, if they are not being maintained/used.
>>>
>>> So if you have any information about the state of the above web  
>>> service sets, or are dependent on these locally, can you please  
>>> let me know.
>>>
>>> See also: http://jira.sakaiproject.org/browse/SAK-18136
>>>
>>> thanks,
>>> Steve
>>> _______________________________________________
>>> 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"
>>>
>>>
>
>
>