[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plans for automated bapc?



Thanks Ken and John for those thoughts. I can answer a few things right away:


Can I just see the calendar of events?

Yes. The link I sent before was the subcription link, but this link should allow anyone to view the calendar, with or without a Google account.


I guess there are some questions about what to include in the weekly
email.  The entries that will be included need to be known about
specially by the script, whereas anything else can be left unprocessed
and go in some page of info.  I would suggest the entries to be included
are Date, Time, Location, Speaker and Zoom link.

Right now, Date, Time, Location, and Title are parsed by the script. Everything else is retained in the calendar event, just in the "note" field. (You can see this by clicking on the single event currently in the calendar.) The easiest thing to do would be to include all of this information in the weekly email, but we could do further parsing.


I haven't seen the calendar, but I suppose there must be a place to
click on the listing to get the details like the abstract.  Maybe a link
to that page should appear with each event in the weekly email.

That's correct, as you can see with the link above. Regarding the weekly email, that's a good idea. Here's an example link for a single event listing. (Note that if you are signed into a Google calendar that has the event added, it will just load your calendar and highlight the event. If you're not logged in, or aren't subscribed, then it will show you a standalone page with the details of this single event.)


I don't know whether anyone should be able to submit.

Suggestion: it would be trivial to restrict to .edu addresses (or a particular set of domains), and that would probably protect against almost all abuse. What do you think?


Similarly I'm sure you should be able to delete
and modify your own postings.  I'm not sure if anyone should be able to
modify and delete them.

As you say, it will be essential to apply access controls and to enable deletion, or perhaps editing (although deletion + resubmission may suffice).

Yes, this is more complicated. Right now, it would be a little nontrivial to cleanly match postings with their submitters to do this kind of granular permission filtering—once the event is created, the system keeps no record of who created it. One thing I could do easily would be to add the submitter's email address to the event (e.g. "Submitted by bvl mit edu"). That would make it easy to grant permissions later on, but it would make the submitter public. We could also have a list of privileged email addresses with update / delete permissions.


I presume/hope we will be able to set up the service so that we will or will not receive an e-mail each time there is a change to the calendar.

The easiest way to do this would be to subscribe to the Google Calendar, and then you can turn on email notifications for any changes to the calendar. Do you think that's sufficient? In principle, we could also have a list of email addresses to receive direct notifications, although that increases the complexity.


Will the e-mail be sent in plain text (vs RTF or with images), or at least will plain text will be an option? Some e-mail systems will not download images or process rich text. I am anticipating that at some point, submitters will want to add images or PDF abstracts or even video previews, but a URL a web page with the images/abstracts would be preferable for some of us with strict e-mail systems.

Currently, the digest emails are sent in plaintext. It is easy to support rich text (as HTML), and it's also possible in principle to include attachments directly. There are a couple of issues with attachments, though. First, the listserv itself has a maximum message size, which might be problematic. Second, there isn't a great way to embed attachments into Google Calendar events. So, I think any attachments would ultimately have to be included only as URLs, unless we want to substantially increase the complexity of the system.


Best,
Ben