**** BEGIN LOGGING AT Fri Jul 2 12:37:17 2004 | ||
-->You are now talking on #schooltool | 12:37 | |
-->alga (~alga@office.pov.lt) has joined #SchoolTool | 13:30 | |
---You are now known as mg|lunch | 14:20 | |
---Disconnected (). | 14:20 | |
**** ENDING LOGGING AT Fri Jul 2 14:20:15 2004 | ||
**** BEGIN LOGGING AT Fri Jul 2 17:30:14 2004 | ||
-->You are now talking on #schooltool | 17:30 | |
th1a | If we can, I'd like to pick up on something mgedmin was wrote yesterday: | 18:38 |
---|---|---|
th1a | specifically, "If we want to make schooltool a web app, I think it would be better to create a new view package" | 18:38 |
th1a | I think we do need to make SchoolTool a web app, sooner rather than later. | 18:39 |
alga | uh, unfortunately, views are more than half of the code we have, I'm afraid | 18:39 |
th1a | That's why I wanted to follow up on that... | 18:40 |
alga | but probably we can reuse a lot of that code | 18:41 |
th1a | Reuse a lot of that code when implementing an HTML interface throughout? | 18:41 |
mgedmin | I would like to start by sketching some mockup user interface, use cases, that sort of thing | 18:41 |
mgedmin | and then look into how it would be better to implement that user interface | 18:42 |
th1a | Sure. | 18:42 |
th1a | An HTML interface, you mean? | 18:42 |
alga | on the other hand, maybe we want to leave the RESTive interface as it is and make the web app more like a proxy | 18:42 |
th1a | That is a possibility if performance is OK. | 18:42 |
th1a | Having a pervasive web services API is important in presenting SchoolTool as a platform | 18:43 |
th1a | Not just another school admin app. | 18:43 |
alga | right | 18:43 |
SteveA | I suggest against that | 18:44 |
SteveA | by all means leave the REST interface | 18:44 |
th1a | Against which? | 18:44 |
SteveA | but I think schooltool needs to become a web app in itself | 18:44 |
SteveA | not having a web app as a proxied REST interface | 18:44 |
th1a | It doesn't seem like a proxied approach would be fast enough. | 18:45 |
SteveA | it would be more complex. | 18:45 |
mgedmin | I'm also in favour of building a web app directly, and not as a proxy | 18:46 |
alga | then we'll have two sets of views | 18:47 |
th1a | Yes. | 18:47 |
mgedmin | yes | 18:47 |
alga | one of them will be the favoured one | 18:47 |
mgedmin | huh? | 18:47 |
alga | the other one will be lagging behind | 18:47 |
mgedmin | I see your concern | 18:47 |
alga | being inadvertently broken | 18:47 |
alga | nobody will notice since it won't be used in real life | 18:48 |
th1a | Which wont? | 18:48 |
mgedmin | unless we keep tests | 18:48 |
alga | sure, we will keep trying | 18:48 |
mgedmin | keep writing tests I mean | 18:48 |
alga | tests don't cover everyting | 18:49 |
alga | so, unless there will be a real-life client exercising those interfaces, there will be breakage | 18:49 |
alga | like ftp or dav in Zope3 | 18:49 |
th1a | The thing is, if there is an HTML interface, I'm sure the large majority of use will be via the web. | 18:49 |
alga | true | 18:50 |
th1a | I guess I see the XML interface as something we are able to provide | 18:50 |
mgedmin | that's why I long for acceptance tests that cover the end-user requirements completely | 18:51 |
th1a | thanks to our lack of need for immediate profit. | 18:51 |
th1a | Acceptance tests? | 18:51 |
th1a | Perhaps that's something I should do. | 18:53 |
mgedmin | th1a: are you familiar with Extreme Programming? | 18:53 |
th1a | mgedmin: I read the book a while ago. I guess I need to reread it. | 18:56 |
th1a | I think the calendaring release needs to have an HTML interface. | 18:58 |
alga | our calendaring code mostly has it, as you might have noticed :-) | 19:00 |
th1a | Yeah. It'll just need to be fleshed out, and allow for editing calendars through the web. | 19:01 |
alga | by the way, how is that release going to happen? we have just a little of dev time paid for. Do we need to present a new proposal to Mark? | 19:01 |
th1a | Part of the reason I'm asking all these questions is to figure out what should be in the next proposal. | 19:02 |
th1a | Making sure it doesn't have to include ripping out half of SchoolTool :-) | 19:03 |
th1a | I would like to set an end date for the current contract, wrapping up the logging work. | 19:06 |
alga | and ssl support for the clients? | 19:15 |
th1a | Yeah. | 19:18 |
th1a | Whatever was in the existing contract. I'm not trying to squeeze anything else in. | 19:18 |
alga | ok, fine | 19:20 |
th1a | So if you guys could come up with a time frame for finishing the current contract, I'd appreciate it. | 19:52 |
alga | uh... | 19:59 |
alga | tentatively, a couple of weeks | 20:04 |
alga | but we haven't scheduled it yet | 20:04 |
alga | as Steve asked us to postpone the work, we got into another project. | 20:05 |
alga | there is approximately a week's worth of work left to do | 20:06 |
alga | actually, it's up to you really to dictate the schedules now :-) | 20:06 |
th1a | I'm easing into that. | 20:11 |
th1a | I'd like it to be done in three weeks. | 20:11 |
th1a | How's that? | 20:11 |
alga | possible, I think | 20:12 |
alga | but I'm going for a two week vacation starting Monday, so it's all up to Marius and Gintas :-) | 20:12 |
th1a | You Europeans and your vacations... | 20:13 |
th1a | :-) | 20:14 |
th1a | Well, discuss it among yourselves and get back to me. | 20:14 |
th1a | Three weeks gives me time to get the specs together for the calendar release. | 20:14 |
---th1a is now known as th1a|lunch | 20:21 | |
alga | OK, three weeks is fine for us | 20:25 |
alga | most probably it will be done in one or two weeks though. | 20:33 |
---th1a|lunch is now known as th1a | 21:09 | |
th1a | That sounds good. | 21:11 |
---Disconnected (). | 22:59 | |
**** ENDING LOGGING AT Fri Jul 2 22:59:43 2004 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!