Closed Bug 264574 Opened 20 years ago Closed 20 years ago

libxpical directory cleanup

Categories

(Calendar :: Internal Components, defect)

Product:
Calendar
Component:
Internal Components
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: vlad, Assigned: mostafah)

Details

With the upcoming flurry of libxpical hacking, I'd like to suggest a
cleanup/file layout rearrangement.  Right now, the public interfaces, the
libical impls, tests, etc. are all jumbled together into one directory.  I'd
suggest a separation similar to the other modules in the tree:

libxpical/
  public/
    oeIICal.idl (possibly split up into a few .idl files by interface)
  src/
    ical/
      oeICalImpl.{cpp,h}
      oeICalTodoImpl.{cpp,h}
      oeICalEventImpl.{cpp,h}
      oeICalContainerImpl.{cpp,h}
      oeDateTimeImpl.{cpp,h}
    storage/
      oeStorageCal...
    webdav/
      oeWebDavCal...
  build/
    oeICalFactory.cpp
  tests/
    TestIcal.cpp
    caltst.js
    caltst.xul

Thoughts?  This would require someone to do some cvs back end surgery, to
preserve revisions and the like.
I can do the CVS surgery when we decide what we want.
The cleanup sounds like a great idea.

two questions, may not totally related to this:
- do we want to keep the name libxpical, if we support other storages beside ical?
- Do we really want to reimplement oeIICalEvent for every storage mechanism?
most will be almost exact copies, because the impl doesn't do much ical related.
(In reply to comment #2)
> The cleanup sounds like a great idea.
> 
> two questions, may not totally related to this:
> - do we want to keep the name libxpical, if we support other storages beside ical?

Maybe just "xpcal"?  I'm easy on that one.

> - Do we really want to reimplement oeIICalEvent for every storage mechanism?
> most will be almost exact copies, because the impl doesn't do much ical related.

I'm not sure they will -- for the mozStorage back-end at least, modifying the
oeIICalEvent will modify the stored data directly; I assume that it will do the
same for the caldav back end, though that one will probably want some batching.
(In reply to comment #3)
> (In reply to comment #2)
> > The cleanup sounds like a great idea.
> > 
> > two questions, may not totally related to this:
> > - do we want to keep the name libxpical, if we support other storages beside
ical?
> 
> Maybe just "xpcal"?  I'm easy on that one.
I believe the "ical" part of the name presents the interface and the logic of
the functionality more than the storage. Note that the interface is oeIICal not
just oeICal. Throughout the implementation and when defining the interface it
has been assumed that the iCal standard is the defining logic. If that is not
desired, a more general nsICal interface ( probably in /base ) can be defined
holding the common parts and oeIICal will use it as a base interface.
If we agree with that, removing the "lib" doesn't add much value and will just
cause some work for places (code and docs) where it has to be changed.
Other than that, the rearrangement looks good.
Side note: The new names can be ns instead of oe
Ok, it makes sense to base everything off ical, because then we are sure
exporting won't loose any data, and sharing the ical file still works.
The name-change was just an idea. I wan't really worry if we don't change the
name :)
Creating a base-idl and a ical-idl won't work i think, because then the frontend
will have to know what kind of event it is looking at. And imo, that's a bad
idea. The frontend should not worry about which backend is used.
Not all our calendars are going to have ICS-file back-ends, though, so it may
well not make sense to have that be the core.  I need to spend some more time
making vlad spend more time thinking about that, though.  (CalDAV is one, the
oft-discussed hypothetical Exchange connector is another.)

The front-end may well have to know about the type of event it's dealing with,
though "type of" should probably mean "meaningful operations on this are X, Y,
Z" and not "came from backend FooCal".

What do you mean by "basing everything off ical"?
(In reply to comment #6)
> The front-end may well have to know about the type of event it's dealing with,
> though "type of" should probably mean "meaningful operations on this are X, Y,
> Z" and not "came from backend FooCal".

Then some impl's just throw NS_ERROR_NOT_IMPLEMENTED. The backend should have to
try to QI to interfaceA, if fails to interfaceB, etc in order to find out if
some operation is possible.

> What do you mean by "basing everything off ical"?

I mean that ical is the basic idea. I think we want to be able to export to ical
without loss of information. That way, you can share the file over http or whatever.
So even if the actual storage isn't ical, ical would still be important.
(In reply to comment #7)
> Then some impl's just throw NS_ERROR_NOT_IMPLEMENTED.

> > What do you mean by "basing everything off ical"?
> 
> I mean that ical is the basic idea. I think we want to be able to export to ical
> without loss of information. That way, you can share the file over http or
whatever.
> So even if the actual storage isn't ical, ical would still be important.

Lossless export doesn't require that ical be the fundamental unit of calendar
data, or the definition of all our operations, though.  Roundtripping through
ical is very important indeed, but if we hit a case where we can't express
something that we want to do in ical then I'd rather we suffer in terms of
pure-ICS interop than not be able to do it at all.  And export/import is
typically a less frequent operation than altering/searching/viewing calendar
data, so I'd rather not optimize too much -- in terms of time/space or
architecture -- for those cases.
(In reply to comment #7)
> Then some impl's just throw NS_ERROR_NOT_IMPLEMENTED.

Ahem.

Yeah, that's fine.  I just didn't want to see us wander into the trap of trying
to define One True Calendar Event interface a priori.  That way lies, well, RDF.
RIP lipxpical
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Mass move of libxpical bugs to the Internal Components, per ctalbert.
Component: libxpical → Internal Components
The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!
QA Contact: gurganbl → base
You need to log in before you can comment on or make changes to this bug.