217552 - Develop neutral Calendar interfaces

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[Mike Young]

we need an implementation agnostic way of hooking in different types of
calendars into the Calendar Application. 

As it stands now, iCal has its own interface, the SunCDE component has its own
interface, and if we ever want to add anything else, we'll need out own then too.

A common base interface with different implementations is the way we need to go.

Comment 1

[Mike Young]

Attachment: neutral Calendar interface IDL

After a long wait, here finally is our proposed neutral interface for a
Calendar. since all queries are handled in the container and query layer, we no
longer should have to duplicate code in the calendar itself for things like
"getbyDay" and "getByMonth" instead we have a simple doQuery function.

This is our starting point, and we'd love to hear any comments.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 135866 [details]
neutral Calendar interface IDL

My random comments on this:

>[scriptable, uuid()]
>interface psuICalendar

I personally don't really like all kinds of prefixes in one component. oeIFoo,
psuIFoo. I whish they all were calIFoo. Descripbe the component, not the
author.

>  void connect();
>  void disconnect();

Why would you want to disconnect? Why would you want to connect later? Why not
let the init handle the connection, and then just leave it open. You need to
wait for updates anyway.

>  void authenticate(in string user, in string pass);
Should happen on connect.

>  /**
>   * Add the calendar to the backend
>   */
>  void addCalendar();

Eh? which backend? Would this upload some calendar to the server or something?

>  /**
>   * Get a calendar list from the backend
>   */

Didn't this interface describe a calendar? How can it have a list of calendars?

And how do i get events out of the calendar? Shouldn't it have some list?

Comment 3

[Mike Young]

(In reply to comment #2)

> >[scriptable, uuid()]
> >interface psuICalendar
> 
> I personally don't really like all kinds of prefixes in one component. oeIFoo,
> psuIFoo. I whish they all were calIFoo. Descripbe the component, not the
> author.

I agree. Of course it would be very bad to start randomly changing interface
names now. For the interaces yet to be made (at the moment psuI) we could
probably change them to calI. We had them as psuI for accountability originally.

> >  void connect();
> >  void disconnect();
> 
> Why would you want to disconnect? Why would you want to connect later? Why not
> let the init handle the connection, and then just leave it open. You need to
> wait for updates anyway.

This depends on the server, the user, and more. Why would you want to disconnect
from your mail server? why don't you just stay connected all the time? The
reason is because pop3 mail (like many different types of mail servers) works in
a transaction-oriented system. You connect, get messages, disconnect.

Similarly, several calendar servers (example, Lotus Notes) work the same way. A
connection is made, the calendars are replicated, the connection is severed.
This allows people to use the calendar without requiring a constant connection
(dial-up) and save the server from a ton of traffic.

> 
> >  void authenticate(in string user, in string pass);
> Should happen on connect.

I disagree. Again, this depends on the situation. Some servers require a
seperate authentication for every connection, and others require authentication
for every transaction. We seperated this out for that very reason. Allow the
implementation to call authenticate whenever it is needed without having to
disconnect and reconnect constantly.

> 
> >  /**
> >   * Add the calendar to the backend
> >   */
> >  void addCalendar();
> 
> Eh? which backend? Would this upload some calendar to the server or something?

Yes. creating a new calendar on the Server or database store, etc

> >  /**
> >   * Get a calendar list from the backend
> >   */
> 
> Didn't this interface describe a calendar? How can it have a list of calendars?
> 
> And how do i get events out of the calendar? Shouldn't it have some list?
> 

You're a little confused... mainly because we don't have a simple standard
terminology for what we are doing.

This is an interface to a backend calendar - defined in our plan as a translator
between a server and a neutral internal mozilla calendar.

Basically, this means that this interface should handle whatever gets done with
a server. You should be able to add (and potentially remove) a calendar, and get
a list of calendars available to you. This requires connecting, authenticating, etc.

Getting the events from a calendar is handled by the DoQuery function. The
"list" of events is the nsISimpleEnumerator (whose function and use we are
slightly shaky on). The crux of this plan (the part my thesis for school is on)
is this query interface. Instead of having every single implementation deal with
the hassle of "GetEventsByDay" or "GetNextNEvents", etc we simply translate
those calls in the Query Layer into a standard, agnostic, arbitrary query that
could represent any possible query we could pose. (Get next N events from the
next 4 days except for Tuesday... for example)

The implementation then just has to implement one function to get events... the
DoQuery function.

now, with that said, this interface (along with the others) isn't finished yet.
I don't believe we have a way to delete or update events yet, although I could
be wrong.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

Ok, so we have some different terminoligy.
For me, 'a calendar' is a collection of events. Just like the calendars in the
calendars tab. They are jsut a bunch of events in a single file.
To have more flexible ways of storing the collection of event, we need an
interface. The front-end will talk to that interface. All that interface needs
to to is be able to list events, add and delete.
This interface can be implemented in multiple ways. One is the current one local
file with a list of event. An other way may be imap. Or some specialized
calendar server.
Some of those implementations indeed need stuff like authentication, opening
connections etc. Others don't. I think that the front-end shouldn't need to know
about all that. The front-end just ask for a list of events, and displays them.
Or modifies. It is up to the implementation to open the connection, or look in
its cache.

The problem with moving all this to the implementation is duplicated code. We
need some helper stuff. Maybe we need a calIServer interface or something like
that. Or less neutral, calILotusServer. They way the server works is higly
dependent on the server and the connection method. what the front-end wants of a
calendar is always the same.

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

After thinking about this some more, I still think the connect() etc moethods
are implementation details.
Yes, you need to connect to some kind of calendars. You may need to
authenticate. etc. But who will call these functions? If the calendar manager
must do this, it will call it for every calendar. For local files most will be a
no-op.
And the way and order off stuff will vary a lot for different server types, so i
don't think you can generalize it enough. (do you need to select a calendar
first, and then authenticate, or the other way around?)
So, let the component that implements the calICalendar interface do the work.
Ofcourse, we could provide helper functions. For exemple, libical is a helper
library. Local files and ical event in imap both need libical to create an event
object.
In the same way, caching event to prevent a continues connection could be a
helper library.

About quering: a query language of some sort would be real cool. But as long as
we don't have that, a way to get a list off all events is needed. Or maybe
search methods to serach by date-range.

Comment 6

[Mike Young]

PSU is no longer funding students to work on mozilla :-(

The bugs we were working on (with the exception of bug 188660 are now irrelevant
with the massive backend changes that were made to the calendar.

Resolving.