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.
Created attachment 135866 [details] 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 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?
(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.
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.