My comments are just trying to identify what exists already. One can always customize by some amount of programming, and enough source info seems to be available, as well as SDKs for Palm, etc. What you seek (shared calendar subsets) seems to exist and seems described in what I have covered already though I didn't cover all facets in detail. I did shared subsets in my most complex case described earlier, where several subcategories on my laptop were actually several of my calendar sections from my work PC, via my PDAs. I had choices of which calendar sections from 2 PCs went to which of 2 PDAs and the other PC, and did not invoke the native data record field "category" in any way. Some constraint of conduit-level file reference definition required that calendar sections from one particular PC appear as sub-categories on the PDAs and home PC, but that was not a problem for me. The feature to make "categories" within the calendar function is defined within the Conduit Manager for my cases. It's defined in two forms that seem disjoint. The type that is a data record field is unused and maybe useless in my contexts, but both Palm and PC can sort on this field. I end up with a calendar hierarchy where the top level on all PDAs must be one PC's top one, but the second level may be any mix. I think 3rd levels and maybe more could be defined, but I stopped at a single subordinate level to contain the collection of shared and unshared calendar segments. My main point is that the conduit definitions, which are probably a proper subset of the Palm SDK, seem to contain a sufficient set of parameters so one can easily build the calendar subsection sharing one may want. My secondary point is that sticking to defined properties of Palm "Hotsync" interface is an option and probably w very wise idea for portability and growth. NB: I can define exactly which major sections of each PDA data are active in sync and which are "do nothing", or slaved, etc. The PC side is dumb, because it was defined to be "boss" before PDAs that smartness emerged. Trying to shift that paradigm doesn't seem a good idea to me for compatibility (etc). I think I also have the access to define which calendar (and other) subsections are shared also, but that gets *very* messy (my tree and data set is large already) so I try to limit the permutations as much as possible for KISS reasons. Happy hacking! Chuck > -----Original Message----- > From: tclug-list-bounces at mn-linux.org > [mailto:tclug-list-bounces at mn-linux.org]On Behalf Of > rpgoldman at real-time.com > Sent: Saturday, March 13, 2004 8:31 PM > To: cncole at earthlink.net; TCLUG Mailing List > Subject: RE: [TCLUG] Palms and shared calendars > > > >>>>> "Chuck" == Chuck Cole <cncole at earthlink.net> writes: > > Chuck> Offhand, I'd say that what you want is quite easy to do and could link Linux and Windows PCs via the PDAs as > well. Avoiding > Chuck> categories makes things MUCH simpler every way and every day. > > Chuck> I just have "hotsync" set to recognize different PDAs, and multiple PCs (and multiple OS's) was just a matter > of setup options.. > Chuck> that I no longer use for multiple PCs with separate calendars on same PDAs. I used that setup about a year > with daily or more > Chuck> syncs, and still use most of that same setup. I remember most and have some notes, however. > > Chuck> Since the calendars are to be the same on both PCs, your > Chuck> setup should only require recognizing two PDAs to sync on > Chuck> each computer. This is *very* easy using Chapura's > Chuck> PocketMirror under multiple flavors of Windoze and > Chuck> OuchLook, and may be easy in other conduit managers. > > Actually, this isn't what I was saying. What I was saying was that > some SUBSET of the calendars should be shared. > > Also, having me synch my Palm on my wife's computer and her synch onto > mine will be burdensome. > > I appreciate your taking the time to think about this in this way that > works through the Palms rather than through a conduit between two > calendaring (and contacts) programs, but it still seems backwards to > me. Especially since the map from desktop -> palm is lossy. FYI, the Palm side seems to be smarter in control and the superset of data in all in my cases. I believe that shifting the apparent PDA paradigm of being superior to the PC in conduit definition and control will become a *big* departure in architecture, structure and control... read "time hog". I could be wrong, of course. I have not looked at the "netcentric" things I've seen mentioned, and that may be the world you really seek. > I would have thought that there would be a simple third point (call it > micro-Exchange) that would bring them together. > > Evolution *claims* shared calendaring, but AFAICT that just means > Exchange (or some other non-free, business oriented behemoth). > > KDEPIM seems to plan to have an egroupware conduit.... > > Anyone know more than that? > > cheers, > R > > _______________________________________________ _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list