| 00:02.15 | *** join/#gpe XorA|gon1 (n=dp@81-179-82-76.dsl.pipex.com) |
| 00:02.44 | *** join/#gpe pigeon (n=pigeon@218-214-60-232.people.net.au) |
| 00:03.43 | *** join/#gpe _guillermo (n=guillerm@linkwood.informatik.uni-duisburg.de) |
| 00:19.20 | *** join/#gpe france (n=france@pool-151-203-3-175.bos.east.verizon.net) |
| 00:59.41 | *** join/#gpe _guillermo (n=guillerm@linkwood.informatik.uni-duisburg.de) |
| 01:35.28 | *** join/#gpe johanbr (n=j@d154-20-189-105.bchsia.telus.net) |
| 01:41.58 | *** join/#gpe Timelord (n=TL@4.78.4.43) |
| 04:26.04 | *** join/#gpe johanbr (n=j@d154-20-189-105.bchsia.telus.net) |
| 04:58.22 | *** join/#gpe arm-bar (n=user@70.251.84.1) |
| 06:18.59 | *** join/#gpe XorA|gone (n=dp@85-210-44-171.dsl.pipex.com) |
| 06:29.28 | *** join/#gpe pH5 (n=ph5@p5486525F.dip.t-dialin.net) |
| 07:07.51 | *** join/#gpe zap (n=zap@85.249.170.16) |
| 07:47.15 | *** join/#gpe multimode (n=user@70.251.84.1) |
| 08:04.02 | *** join/#gpe BBrox (n=ulmer@bbrox.org) |
| 09:24.19 | *** join/#gpe yang (n=yang@cpe-213-157-253-172.dynamic.amis.net) |
| 10:03.43 | *** join/#gpe Cwiiis (n=cwiiis@82-43-42-18.cable.ubr02.croy.blueyonder.co.uk) |
| 10:28.32 | *** join/#gpe _guillermo (n=guillerm@linkwood.informatik.uni-duisburg.de) |
| 10:36.15 | *** join/#gpe rob_w (n=bob@p213.54.206.86.tisdip.tiscali.de) |
| 11:58.38 | *** join/#gpe hhhcz (n=arnaud@vau06-1-82-228-255-84.fbx.proxad.net) |
| 12:03.35 | *** join/#gpe petterhj (n=TESTID@host-81-191-111-34.bluecom.no) |
| 12:57.42 | *** join/#gpe eyck (i=eyck@ghost.anime.pl) |
| 12:58.32 | *** join/#gpe shiyee (n=Shiyee@0x50c405a4.vgnxx3.adsl-dhcp.tele.dk) |
| 13:08.11 | *** join/#gpe rob_w (n=bob@p213.54.221.102.tisdip.tiscali.de) |
| 15:35.12 | *** join/#gpe reenoo (n=r@p5489EDEA.dip.t-dialin.net) |
| 15:36.16 | reenoo | afternoon |
| 15:43.10 | *** join/#gpe zap (n=zap@85.249.170.16) |
| 15:49.03 | *** join/#gpe Ge0rgy (n=Christop@p54A1387E.dip0.t-ipconnect.de) |
| 15:49.33 | *** part/#gpe Ge0rgy (n=Christop@p54A1387E.dip0.t-ipconnect.de) |
| 16:57.11 | *** join/#gpe zecke (n=ich@88.134.17.180) |
| 17:17.27 | CoreDump|home | hi |
| 17:34.36 | *** join/#gpe rob_w (n=bob@p213.54.221.102.tisdip.tiscali.de) |
| 17:39.28 | *** join/#gpe JiniDog (n=jini@Vaba3.v.pppool.de) |
| 18:05.54 | *** join/#gpe Ge0rgy_ (n=Christop@p54A1387E.dip0.t-ipconnect.de) |
| 18:31.05 | *** join/#gpe florian (n=fuchs@p50839CCB.dip0.t-ipconnect.de) |
| 18:31.39 | florian | hi |
| 18:31.45 | reenoo | hey florian |
| 18:32.13 | florian | hi reenoo |
| 18:35.24 | *** part/#gpe Ge0rgy (n=Christop@p54A1387E.dip0.t-ipconnect.de) |
| 18:43.05 | *** join/#gpe JiniDog (n=jini@Vaebf.v.pppool.de) |
| 19:06.20 | rob_w | how supported are the sharp cl3100 |
| 19:08.57 | florian | neal: I started to work on the event deletion process to be able to generate lists of deleted ones. |
| 19:09.14 | neal | what does your interface look like? |
| 19:17.06 | florian | neal: that would be the next step, i stared with the database :-) |
| 19:17.45 | neal | you have to have a libeventdb interface |
| 19:17.48 | neal | what are you planning? |
| 19:17.55 | neal | and how are you implementing this? |
| 19:20.26 | florian | neal: more or less like you said - marking the events as deleted in the database and filter these in the functions that query the events. |
| 19:20.39 | neal | which table? |
| 19:21.23 | florian | neal: and add a housekeeping function to get rid of the events finally. |
| 19:21.29 | florian | neal: events |
| 19:21.39 | neal | hmm. |
| 19:21.47 | neal | It's not clear to me that that is idea. |
| 19:21.50 | neal | ideal |
| 19:22.00 | neal | the search functions search against that table |
| 19:22.04 | neal | that will slow them down |
| 19:22.11 | neal | on the other hand, we can't put them in the calendar table |
| 19:22.41 | neal | if you delete the last event, the uid will be reused |
| 19:22.52 | neal | (as we get the id from the event table) |
| 19:23.04 | neal | may be we should have a deleted event table. |
| 19:23.18 | neal | it needs to contain the eventid and the calendar the event was in |
| 19:25.09 | florian | yeah, but then we need to match against this to filte the events |
| 19:26.01 | neal | filte? |
| 19:29.04 | florian | argh |
| 19:29.07 | florian | filter |
| 19:29.27 | neal | florian: Why do you mean? |
| 19:29.37 | neal | I think the fast path needs to be searching for events |
| 19:29.53 | neal | we don't need to optimize for new events and deleting events |
| 19:30.52 | florian | true |
| 19:32.37 | florian | do you think it will slow down too much if we filter the events marked as deleted from the events table? |
| 19:32.51 | neal | I think it is a waste |
| 19:32.59 | neal | it basically means more SQL code |
| 19:33.34 | *** join/#gpe paul (i=[U2FsdGV@hibernia.jakma.org) |
| 19:34.12 | florian | neal: if i didn't miss anything important last night i got this part. |
| 19:35.27 | neal | the search code is really important to get fast |
| 19:35.40 | neal | imho |
| 19:38.51 | yang | is bluetooth on ipaq compatible (can link) with linksys wireless router 802.11b/g ? |
| 19:40.53 | univac | :)))) |
| 19:41.06 | florian | very true - well, i can check if my current implementation has negative impact in the performance later - if it turns out it is bad i can change this then. |
| 19:41.18 | neal | I don't know. |
| 19:41.25 | neal | It depends on the number of deleted events |
| 19:41.45 | neal | clear with a small number of delete events, there will be negligible performance impact |
| 19:41.48 | florian | yang: no, bluetooth is something different than 802.11 |
| 19:41.57 | neal | however, how often will house keeping be done? |
| 19:42.12 | neal | I'm for a separate table. |
| 19:45.16 | florian | neal: that's a tricky thing - do we need this list for keeping remote calendars via webdav up to date? |
| 19:45.35 | neal | why do you think it is tricky? |
| 19:46.43 | florian | neal: can we do housekeeping as soon as the sync took place? |
| 19:47.01 | neal | else does not using a new table change that? |
| 19:47.30 | neal | void event_calendar_flush_deleted (EventCalendar *ec); |
| 19:47.45 | neal | that's the interface I imagine for flushing deleted events. |
| 19:47.56 | neal | another point against the unified approach |
| 19:48.10 | neal | for cals you subscribe to, it may be useful to delete events. |
| 19:48.30 | neal | but if the subscription is read-only you can never flush the events |
| 19:48.40 | neal | (until they disappear upstream) |
| 19:48.52 | neal | these will accumulate |
| 19:52.26 | florian | neal: that's true, so let's create a table where we store id and calendar of the deleted events. |
| 19:52.55 | neal | yes. |
| 19:56.23 | florian | then we only need a function to get the list of deleted events per calendar. something like event_calendar_get_deleted (... |
| 19:56.40 | neal | s/get/list/ |
| 19:57.08 | neal | event_db_get_by_event_id should return deleted events |
| 19:57.16 | florian | true, "get" might be misleading |
| 19:57.20 | neal | and a new predicate should be added to determine if an event is deleted |
| 19:57.23 | neal | event_is_deleted |
| 19:59.49 | florian | hmm... why would we need to get the deleted events by id? |
| 20:00.26 | neal | for an import. |
| 20:00.46 | neal | when we import, we check to see if the event is already in the db by looking up its event id |
| 20:01.53 | neal | take a look at import-vcal.c |
| 20:03.22 | florian | need to help here in the background a bit, brb |
| 20:05.35 | florian | ah right, that's true |
| 20:05.54 | florian | hmm... nasty, that implies never to flush this table - imporing could always pull back in a deleted event. |
| 20:06.07 | neal | that's what I said above |
| 20:06.17 | neal | but you can flush after you push |
| 20:06.31 | neal | then you know that the event is really deleted on the server. |
| 20:07.41 | florian | true... i had local import in mind as well - maybe some exported list from a cellphone or a pc app |
| 20:10.16 | florian | maybe we should make that user interactive for local calendars |
| 20:10.24 | neal | what do you mean? |
| 20:10.43 | florian | gah, i need a better accesspoint |
| 20:12.22 | florian | neal: if you import a list of events from some other application you could have old events in it you imported before and deleted on you device. |
| 20:13.10 | neal | It's a function of the type of import |
| 20:13.34 | neal | subscribe: only flush when it is flushed upstream |
| 20:14.07 | neal | publish: flush when it is published |
| 20:14.38 | neal | I don't see why what you refer to as local import doesn't fit one of these categories. |
| 20:17.44 | florian | neal: if you save an ics file to a file, copy that to a rs-mmc card and read this from gpe-calendar on your 770 - that's local and not server driven. |
| 20:18.08 | florian | that doesn't fit in these categories imho |
| 20:18.59 | florian | if it would be subscribe that would be bad for local use and modifications |
| 20:19.19 | florian | and publishing ususally doensn't happen in this case. |
| 20:19.39 | florian | Or did i miss any important point? |
| 20:20.28 | neal | so your saying: what should happen when you import an .ics file and there are events in the file which are also present in the db |
| 20:20.43 | neal | I think you are right, in that case |
| 20:20.50 | neal | that is a third scenario |
| 20:22.08 | florian | right, that's it. |
| 20:58.38 | *** join/#gpe thejapa (n=thejapa@200-232-209-21.dsl.telesp.net.br) |
| 21:20.38 | *** join/#gpe JiniDog (n=jini@Vaebf.v.pppool.de) |
| 21:29.23 | *** join/#gpe stefan_schmidt (n=stefan@85.25.32.104) |
| 22:10.24 | florian | *yawn* |
| 22:31.52 | *** join/#gpe jini_ (n=jini@V92b2.v.pppool.de) |
| 22:45.02 | florian | good night |
| 22:45.10 | reenoo | 'night florian |
| 23:33.07 | *** join/#gpe jg (n=jg@c-24-218-178-107.hsd1.ma.comcast.net) |