[Building Sakai] interactions between 2 import and 2 export functions within calendar?

Adam Marshall adam.marshall at it.ox.ac.uk
Mon Jul 29 05:55:37 PDT 2013


I think there could be a case for having a show/hide public URL. I still believe that having a public calendar URL is useful if you need to circulate an, erm, public URL for a calendar. I agree you could use a private URL but if you circulate this to say all departments in the medical school for display on their front of house display monitors and then somebody regenerates the private URL, all their calendars will break.

We certainly fixed the looping bug. I have CCd Matthew into this email so he can confirm that he committed the patch back. 

I do not know the answer to #2, again, Matthew will know. He'll be at work soon.

We would argue for our button labels but for us it is more important to get the code in 2.10, we've changed all the other labels anyways, so it really isn’t an issue.

adam

-----Original Message-----
From: Keli Sato Amann [mailto:kamann at stanford.edu] 
Sent: 24 July 2013 22:24
To: Adam Marshall
Cc: sakai-dev
Subject: Re: [Building Sakai] interactions between 2 import and 2 export functions within calendar?

Hi Adam,
One of our developers has gotten SAK-21497 running on our 2.10 test instance. Unless you can elaborate on the use case that would require using public calendar URL rather than private URL, we are probably going to eliminate "Subscriptions (export)". 

We are likely to rename "Subscribe" (private URL) to "Get Calendar URL," since subscribe is what you do on the client side. I may also make a few changes to the instructions.

I did have a couple of questions
1) did the infinite loop bug actually get fixed? It wasn't clear from your response. We are planning to get rid of "Subscriptions (import)" just in case--we haven't found anyone using it, but may be asked to restore it in the future.

2) Do you have an update limit set at WebLearn for Oxford and if so, what is it? If not, has overload of your servers been a problem? I guess if you set this a limit in your feed, then you can allow Outlook users to get more up to date calendar feeds, just not too often. I guess some content providers cancel your subscription if you refresh too often so they set a limit. (see outlook screenshots in http://mcb.berkeley.edu/academic-programs/seminars/ical-feed-instructions/) I'm not sure how iCal deals with this, as you can set your subscription to refresh every 5 minutes--maybe it allows it but the publisher has the right to cancel your subscription (not even sure if that would be possible in CourseWork). Or maybe sakai just ignores more frequent requests? 

If the latter, we may position this feature as Beta feature and say that users will not be allowed to update more often than every hour. If the former, I guess we are taking something of a risk that we will get overrun, which we can try to counteract by giving explicit instructions not to update more than once an hour. We might reduce that recommendation to 5 minutes once we see that we can handle the load.

One thing that I've discovered is that iOS seems to work great, refreshing the feed everytime you launch the calendar app. Unfortunately, Android phones work via your google account, so have the same calendar refresh latency problem (more than a few hours) I've mentioned in previous posts. But if we end up having to recommend anything higher than a 5 minute refresh limit, then perhaps we just have to position this as a convenient, if not completely up-to-date, way of checking your course schedule without logging in to the CLE, and warn instructors, as you do, to send an email or make an announcement if they make a last minute change.

If this works out, I guess we would help campaign to get this into 2.10, though I would strongly recommend renaming buttons if so and eliminating public calendar URL. But I am also now hoping Project Ketai might enable a way of checking your course calendars from your phone without having to navigate through several clicks into the CLE--less convenient, but instant.

Best,
Keli

----- Original Message -----
From: "Adam Marshall" <adam.marshall at it.ox.ac.uk>
To: "Keli Sato Amann" <kamann at stanford.edu>
Cc: "sakai-dev" <sakai-dev at collab.sakaiproject.org>, "sakai-user" <sakai-user at collab.sakaiproject.org>
Sent: Saturday, July 13, 2013 12:51:27 AM
Subject: Re: [Building Sakai] interactions between 2 import and 2 export functions within calendar?

I think there is still a case for the export calendar url link whe n you really don't mind your calendar being public. It is very easy for the (what we call) private url to be deleted (and a new one generated) whereas the exported url is more permanent. The trick is with the naming of the links making sure every body knows that the regular export generates a public url.

The exported private url from my workspace does indeed include events from sakai calendars that have been subscribed to. This is double edged as if n sites subscribe to (say) a term dates calendar, you get n copies of those events in the export. This could be fixed without too much trouble but we haven't had time yet.

Oxford is of course a respected seat of research so it was only natural for one of our colleagues (Howard) to set up a circular subscription of calendars to see what would happen. What happened was an infinite loop, a reboot and a superfast exercise in bug fixing.

We can give anybody an account to test drive this feature - we would love to get the feature into 2.10.  Adam
--
Sent from my tablet

Keli Sato Amann <kamann at stanford.edu> wrote:


Hello,
We are really interested in adding is Oxford's SAK-21497, which adds a button called "Subscribe" to your Site or My Workspace Schedule. It generates a random URL for your site or My workspace calendar that you can add to your personal calendar. It is only running on their 2.8 instance, but we'll give it a shot. If we get it to work, we might rename it ("Get URL"?) and get rid of "Subscriptions(Export)" which also generates a URL, but forces you to name your calendar/URL and is therefore not terribly secure--someone might guess it.

I guess we'll find out if no one has tried this, but do events imported into your course calendar (either via "Import" or "Subscriptions(import)") also get put into the exported calendar (either via "Subscribe" or "Subscriptions(Export)")? Also, what happens if you do the reverse: generate a URL  for your course site Calendar, then import it into another site calendar by either method?  I seem to recall some issues but can't find an exact thread or JIRA to look it up.

When we recently upgraded to 2.9, we forgot to uncomment calendar.external.subscriptions.enable=true, so we don't have a Subscriptions(import) button, just an Import. However,  I checked with the one school that was using this feature and they are no longer depending on it. So maybe we won't add this back in if are there any problems with loops.

Keli Amann
User Experience Specialist
Academic Computing Services, Stanford University _______________________________________________
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"


More information about the sakai-dev mailing list