| danielwilms | hey and welcome here :) | 14:02 |
|---|---|---|
| X-Fade | danielwilms: Hi | 14:02 |
| danielwilms | hi X-Fade | 14:02 |
| -!- Jaffa [n=andrew@badger.bleb.org] has joined #maemo-meeting | 14:02 | |
| danielwilms | hey...bergie...u could make it...thats nice ;) | 14:02 |
| bergie | hi | 14:03 |
| bergie | yeah, unless I reach my daily bandwidth cap... crappy hotel WiFi :-/ | 14:03 |
| sopi | hello. that's me ferenc. | 14:03 |
| bergie | anyway, I'm sitting in a RL meeting so my attendance will be limited | 14:03 |
| danielwilms | sopi ahhh...just wanted to ask | 14:03 |
| danielwilms | bergie ok | 14:04 |
| danielwilms | :) | 14:04 |
| danielwilms | i wanted to start with a small update | 14:04 |
| danielwilms | then discuss about how we manage the user data | 14:04 |
| danielwilms | and then we can discuss the things, which are unclear | 14:04 |
| danielwilms | is that ok?? | 14:04 |
| sopi | yes, fine by me. | 14:05 |
| X-Fade | Sure | 14:05 |
| danielwilms | ok...so...i dont know if everybody has seen the wiki page but the status at the moment is like this: | 14:05 |
| danielwilms | the authentication service is up and running and it works quite stable | 14:06 |
| danielwilms | CAS seems to be a nice thing of software...besides some dependencies and the spring stuff it is ok to set it up | 14:07 |
| danielwilms | the wiki is somehow integrated...fought a bit with the php stuff but does not work really smoothly yet...the biggest issue is to allow anonymous readers as well but this does not seem to be to hard | 14:08 |
| danielwilms | right now I am working on the integration of GForge...cannot really say how much time it will take | 14:09 |
| sopi | about Gforge: did you check out the code from "garage" ? | 14:09 |
| sopi | (https://garage.maemo.org/projects/garage that is) | 14:10 |
| danielwilms | sopi...no I took first a clean installation, because I think the authentication was changed in some way, right? | 14:10 |
| danielwilms | sopi...or do you think I should start with that? | 14:11 |
| -!- tekojo [n=tekojo@dasasob.nokia.com] has joined #maemo-meeting | 14:11 | |
| sopi | danielwilms: a clean installation of v4.5.20 ? | 14:11 |
| sopi | danielwilms: taking our version from garage would make it easier to apply the necessary patches (if any) later on. | 14:12 |
| sopi | i am not sure how much code we changed around authentication. | 14:12 |
| sopi | but there are certainly "layout" changes compared to the upstream v4.5.20. | 14:13 |
| danielwilms | the wiki is done in a way, that the the link is redirected from the old url to the new one | 14:13 |
| danielwilms | so it should not change too much | 14:13 |
| danielwilms | only add stuff | 14:13 |
| danielwilms | and then it gives the name it gets from cas to the component | 14:14 |
| X-Fade | danielwilms: There are auth plugins for mediawiki. | 14:14 |
| X-Fade | So you can plug in authentication without needing to redirect or hack. | 14:14 |
| sopi | X-Fade: good point. we have that for Gforge auth at the moment. | 14:14 |
| sopi | i mean: mediawiki authenticates thru a plugin. | 14:15 |
| danielwilms | it is not really a hack :) i followed a description cas points to...and the mediawiki plugin for cas seems to be quite a hack :) | 14:15 |
| X-Fade | danielwilms: Well, we can always clean it up. | 14:15 |
| X-Fade | I think we have larger problems to address first though ;) | 14:16 |
| danielwilms | the way it works is similar...and it is not really maintained | 14:16 |
| danielwilms | in the readme it was like: "and now pray that it works" :D | 14:16 |
| danielwilms | and phpCAS is pretty much straight forward | 14:17 |
| danielwilms | X-Fade but if you wanna have a look how it is done we can have a look later on | 14:18 |
| X-Fade | danielwilms: Sure, mediawiki will not be the hard part. | 14:18 |
| danielwilms | nope...this was the reason I began with it ;) | 14:18 |
| danielwilms | but back to gforge...I can use the version from garage...I guess this would make more sense | 14:19 |
| danielwilms | thx for the hint sopi | 14:20 |
| sopi | danielwilms: sure. let me know if you need a hand with that. | 14:21 |
| danielwilms | sopi...I will come back to this! :) | 14:21 |
| danielwilms | then the user-management...I think this is a bit tricky part... | 14:22 |
| danielwilms | I would like to abstract the information, the users enters from the application, so that any application can request the basic user-data and use its own user-management like groups and so on | 14:23 |
| danielwilms | so that we would have a user interface where the user can register and update his/her data | 14:24 |
| danielwilms | and the applications could 1) use directly ldap to access the data or 2) get the data by a REST endpoint | 14:25 |
| danielwilms | any opinions on that?? | 14:25 |
| X-Fade | And you would need to remove all account management links from every service. | 14:26 |
| X-Fade | And point them to the central one? | 14:26 |
| bergie | danielwilms: the idea was that the user management UI would be in Midgard | 14:26 |
| bergie | ...using slightly modified version of current profiles there | 14:27 |
| bergie | and then Midgard would sync the stuff to LDAP | 14:27 |
| X-Fade | Or the applications would need to be smart enough to not use a database as backend, but the ldap. | 14:27 |
| danielwilms | the idea is that the basic usermanagement would be apart of any specific component | 14:29 |
| sopi | danielwilms: why? | 14:29 |
| danielwilms | and that every application as such would get the basic user-information from there...because it would make it much more flexible | 14:29 |
| X-Fade | We would need to hack each application to get the appropriate information from ldap anyway. There is no flexible way about that ;) | 14:30 |
| sopi | yes, I agree with X-Fade. | 14:31 |
| danielwilms | but this is the reason for the proposal :) | 14:32 |
| X-Fade | On the other hand we would need to describe which service needs what information. | 14:32 |
| bergie | danielwilms: yes... LDAP would be the "master repository", but on Midgard we already have the editing interface for the data, and probably best opportunities to adapt it to whatever will be needed | 14:33 |
| X-Fade | Do we keep local accounts in the service? | 14:33 |
| danielwilms | as we have to find a way to get the user-information of a central place i thought this might be the "cleanest" solution and it would make it easier to adopt other services later on to this | 14:33 |
| X-Fade | danielwilms: You are talking about a simple web form on top of the ldap server. | 14:33 |
| X-Fade | danielwilms: That can be implemented anywhere? | 14:34 |
| bergie | again, why do that when we already have quite a rich editing UI for editing person info | 14:34 |
| bergie | info that we only need to send to LDAP | 14:34 |
| danielwilms | X-Fade: it could be implemented everywhere, and yes this would keep the local accounts | 14:35 |
| X-Fade | danielwilms: How would a local account change when I change anything in ldap? | 14:35 |
| X-Fade | danielwilms: How does that update end up in the local account? | 14:35 |
| bergie | X-Fade: the "local accounts" must sync from LDAP every now and then | 14:36 |
| danielwilms | the username would be unique and stay...the local account only uses the username to create groups or whatever is needed...and if data would be needed, which is entered by the user itself it will be requested from the user management system | 14:37 |
| X-Fade | danielwilms: Yeah, but that means we need a sync mechanism. | 14:37 |
| X-Fade | danielwilms: If I change my email in ldap, it should change in mediawiki too | 14:37 |
| X-Fade | And it should happen instantly. | 14:38 |
| X-Fade | Otherwise the user browses to his user account in mediawiki and sees the old value still there. | 14:38 |
| bergie | X-Fade: instant is not realistic with the different systems we use, but if we use signals to trigger synchronization, it can be almost instant | 14:38 |
| X-Fade | You know that is going to give us a lot of bug reports ;) | 14:38 |
| danielwilms | this could be done if we would use a service for that | 14:38 |
| bergie | also, if the account editing UI says "this will take a while", then the user knows what to expect | 14:38 |
| X-Fade | bergie: Yeah, but we see this problem with garage->midgard syncing for instance. | 14:39 |
| danielwilms | but the alternative would be to use one ldap for everything and the applications use it directly | 14:39 |
| X-Fade | People can't start doing things instantly, they have to wait. | 14:39 |
| bergie | X-Fade: garage->midgard is quite silly ATM because it syncs *every account* on every run | 14:39 |
| bergie | if Midgard is the UI we can do this with more granularity | 14:39 |
| bergie | danielwilms: I don't think making all apps use LDAP directly is realistic | 14:40 |
| X-Fade | bergie: Yeah, but we now have to see that we sync between: garage, midgard,mediawiki, bugzilla and talk without too much delay. | 14:40 |
| danielwilms | bergie: that was my point | 14:40 |
| bergie | X-Fade: yes, but with Midgard we'd at least know (and get D-Bus signal of) which user was being edited | 14:41 |
| X-Fade | People don't care about our problems. They see the same layout, so it _has_ to be the same ;) | 14:41 |
| bergie | making triggering the syncs easier | 14:41 |
| danielwilms | but we could implement it like cas | 14:41 |
| danielwilms | and the logout | 14:41 |
| X-Fade | bergie: true. we could us dbus to signal an update. | 14:41 |
| danielwilms | if a user logs out it sends a ping to the services | 14:41 |
| X-Fade | danielwilms: interesting | 14:42 |
| danielwilms | thats it...only an endpoint for it would be needed | 14:42 |
| bergie | X-Fade: yep, that is the *other* reason why Midgard would be good editing UI for user info... the other is that there we can control the user experience better than elsewhere | 14:42 |
| X-Fade | danielwilms: But then we could fire an update ping too? :) | 14:42 |
| bergie | danielwilms: exactly that kind of ping/signal is what I'm proposing here | 14:42 |
| danielwilms | so that would be fine with me :)) the only thing we would need to decide if we would do that in midgard or apart from it as a UI for the ldap | 14:44 |
| bergie | danielwilms: yep. but with Midgard we already have it :-) | 14:44 |
| bergie | the d-bus signal can easily be "aggregated" to some web service calls that initiate the sync in various systems | 14:45 |
| X-Fade | And what would we do with things like this page: https://wiki.maemo.org/Special:Preferences | 14:45 |
| danielwilms | yep...thought about that as well as a simple web service set up | 14:45 |
| X-Fade | Are we allowing people to change their account settings in local service forms? | 14:46 |
| danielwilms | bergie: but at the moment we are using garage for the user accounts, right?? | 14:46 |
| bergie | danielwilms: for registration, yes | 14:46 |
| bergie | danielwilms: but after that they may be edited in Midgard | 14:46 |
| bergie | ...as Midgard has more user data than Garage does (accounts in external sites etc) | 14:46 |
| bergie | what I propose is that we'd move also registration to Midgard (the component supports that but it is now disabled) | 14:47 |
| bergie | ...and make Midgard sync to LDAP + ping other services to sync from LDAP | 14:47 |
| sopi | imho we have to agree on the exact set of user data that is stored in LDAP. all other application specific preferences could be still managed by the applications itself. | 14:48 |
| danielwilms | bergie: hmmm...havent thought about that but at the moment I don't find any reason against this :) | 14:48 |
| X-Fade | Can blobs be stored in ldap too? | 14:49 |
| bergie | danielwilms: great, then we can focus on the practicalities :-) | 14:49 |
| sopi | X-Fade had a question about editing certain data in apps. | 14:49 |
| X-Fade | Thinking of avatars? | 14:49 |
| bergie | X-Fade: we could just provide standardized avatar URL with a fallback out of Midgard | 14:49 |
| bergie | you know, http://maemo.org/profile/x-fade.jpg or something like that | 14:50 |
| danielwilms | initially I thought that we have like all the data, which the user actively enters in a common interface to keep it as an abstraction of the rest | 14:50 |
| bergie | which would provide our fallback image if user hasn't posted avatar | 14:50 |
| X-Fade | yeah, but services like talk would need an avatar too. | 14:50 |
| bergie | danielwilms: which would also have the advantage that user would need to edit his info in only one place | 14:50 |
| bergie | X-Fade: yes, but they could just link to that URL? | 14:50 |
| X-Fade | So yeah, we can do it by just linking to a default one . | 14:51 |
| danielwilms | bergie...yes...this was the thought behind it | 14:51 |
| bergie | +1 from me | 14:51 |
| bergie | *if* we can disable the editing UIs in the other systems, as probably they won't sync back to LDAP | 14:51 |
| danielwilms | bergie...at least in the wiki you can | 14:52 |
| bergie | and since our garage is a fork anyway, probably there too ;-) | 14:52 |
| X-Fade | But you would need to disable only certain things. | 14:52 |
| sopi | bergie: yes, but then we need to disable other "user preference" editing as well. | 14:53 |
| X-Fade | FOr wiki, you should not be allowed to change your email. But all other options should still work. | 14:53 |
| bergie | sopi: the prefs could also come from Midgard->LDAP->Garage | 14:53 |
| sopi | might be troublesome to migrate the other "prefs" to LDAP or elsewhere. | 14:53 |
| X-Fade | E-mail me when a page I'm watching is changed | 14:53 |
| X-Fade | E-mail me when my user talk page is changed | 14:53 |
| X-Fade | E-mail me also for minor edits of pages | 14:53 |
| X-Fade | Send me copies of emails I send to other users | 14:53 |
| X-Fade | These sort of options should really stay local. | 14:54 |
| danielwilms | X-Fade but this is the point that you could do it in a central place | 14:54 |
| X-Fade | good luck programming storing these values in ldap. | 14:54 |
| X-Fade | If you want to touch that, then you are really hacking in the core of the service. | 14:54 |
| X-Fade | which is a lot of work :) | 14:55 |
| danielwilms | nooo..the only information you need for that is the email address...and this you could still store locally | 14:55 |
| sopi | X-Fade: i have to second your opinion. Such change in garage would make the gap even bigger between the upstream GForge. | 14:55 |
| danielwilms | with a ping which tells when the user updates it | 14:55 |
| X-Fade | danielwilms: I think just disabling some fields is a lot easier.. | 14:56 |
| -!- tekojo [n=tekojo@dasasob.nokia.com] has left #maemo-meeting [] | 14:56 | |
| danielwilms | X-Fade: ok...but this would need a closer look how it's implemented | 14:57 |
| X-Fade | danielwilms: There is no way around that. | 14:57 |
| X-Fade | danielwilms: Either you hack forms or you hack the preferences storage engine. | 14:57 |
| danielwilms | X-Fade: you are right | 14:58 |
| danielwilms | so...lets put the things together | 14:58 |
| danielwilms | what we need is a central place to edit/register and so on | 14:59 |
| -!- JimiDini_iphone [n=JimiDini@ip-83-149-3-230.nwgsm.ru] has joined #maemo-meeting | 14:59 | |
| danielwilms | this should contain a service, which handles the updates for the applications | 14:59 |
| danielwilms | or better, which pings the others | 15:00 |
| danielwilms | the single applications would contain still locally the data | 15:00 |
| danielwilms | and this service would be realized on top of midgard | 15:01 |
| X-Fade | Another subject to talk about is account merging. | 15:03 |
| danielwilms | yep | 15:03 |
| X-Fade | You can basically have 3 accounts now. garage/midgard, bugzilla and talk. | 15:03 |
| danielwilms | has bugzilla somehow a "user history" | 15:04 |
| X-Fade | danielwilms: In what sense? | 15:04 |
| danielwilms | what I mean is would it hurt to get a new account? | 15:04 |
| sopi | yes it would. | 15:04 |
| X-Fade | Yes, that would hurt. | 15:04 |
| X-Fade | But username=email | 15:05 |
| sopi | we got to keep a "bugzilla ID" in the new system, otherwise the bugzilla account merge will be nightmare. | 15:05 |
| Jaffa | All three have email addrs, but garage/midgard is the only one which supports multiple addresses | 15:05 |
| X-Fade | Jaffa: Yeah, I meant that you can't use a username in bugzilla as it uses your email address. | 15:06 |
| X-Fade | We could do an automated run for every account where username and email match, and the remaining people to login to other services through a central form. | 15:07 |
| X-Fade | So we can merge them that way. | 15:07 |
| danielwilms | yep...this would be an option...i only hope that talk is not too different | 15:08 |
| X-Fade | * ask remaining people to | 15:08 |
| danielwilms | as it was separated all the time | 15:08 |
| X-Fade | danielwilms: username and email are available there. | 15:08 |
| danielwilms | and I dont know how many matches you can expect there | 15:08 |
| X-Fade | But there can be username overlap between the 2. | 15:08 |
| Jaffa | usernames don't necessarily match ;-) | 15:08 |
| X-Fade | Nope | 15:09 |
| * Jaffa puts in a feature request for merging 'aflegg' and 'jaffa' at the same time ;-) | 15:09 | |
| danielwilms | i guess this is the big problem with talk | 15:09 |
| danielwilms | haha | 15:09 |
| X-Fade | Jaffa: People with multiple accounts at the same service should be punished. | 15:09 |
| X-Fade | Well, we do that by just throwing away all others ;) | 15:10 |
| Jaffa | X-Fade: I've been punished - I'm not getting any of my deserved karma for `aflegg' and have lost his `Oct 2005' join date ;-p | 15:10 |
| danielwilms | X-Fade they already complained about a new design | 15:10 |
| danielwilms | :D | 15:10 |
| Jaffa | talk may still need the account for db integrity; but dunno if it has a "locked" feature to prevent log in | 15:10 |
| X-Fade | Jaffa: Just kidding. | 15:10 |
| X-Fade | But yeah, there are multiple problems in a merge. And a 3way merge doesn't make it easier. | 15:11 |
| X-Fade | And then there is another big problem. Login once, be logged in everywhere. | 15:12 |
| JimiDini_iphone | Ideally, we'll need to take one of the services as basis and let people merge others manually if case is not trivial | 15:12 |
| sopi | ..and that should be handled upon the 1st login once the new system is in place.. | 15:13 |
| sopi | each application should force this, in a way. | 15:13 |
| Jaffa | JimiDini_iphone: agreed. But the UI should probably be better than the current midgard/talk account integration field | 15:13 |
| sopi | i see no other ways for automatically merge accounts. | 15:13 |
| X-Fade | Creating a form with 3 login boxes is not that bad. | 15:14 |
| X-Fade | As long as we only present it once. | 15:14 |
| JimiDini_iphone | sopi: Sounds reasonable | 15:14 |
| Jaffa | X-Fade: good idea | 15:14 |
| X-Fade | But this would mean that you can only have one account per service ;) | 15:15 |
| Jaffa | X-Fade: I'm resigned to being odd ;-) | 15:15 |
| danielwilms | :D | 15:15 |
| X-Fade | Jaffa: Well, we might be able to do a search/replace in our database to fix your problem. But yeah :) | 15:15 |
| sopi | X-Fade: wait a sec. can you pls explain step-by-step how the "3 login boxes" idea would work for user "ferenc" for example? | 15:15 |
| sopi | let's say i want to update my bugs in bugzilla. | 15:16 |
| sopi | what will i do? | 15:16 |
| X-Fade | sopi: Login box for garge, bugzilla, talk. | 15:16 |
| sopi | so i take the bugzilla box, fill in, and submit? | 15:16 |
| X-Fade | Enter all your usernames and passwords there. Click submit. | 15:16 |
| sopi | ah, i see. | 15:16 |
| X-Fade | On the server read back the responses from all services. | 15:16 |
| sopi | in that case the system will know about my all credentials. | 15:16 |
| X-Fade | And request userids. | 15:16 |
| X-Fade | Once, and we don;t have to store them. | 15:17 |
| danielwilms | X-Fade sounds like a really good idea | 15:17 |
| sopi | yes, i see. would work. | 15:17 |
| X-Fade | And we are a trusted party for all those services anyway. | 15:17 |
| sopi | yes. | 15:17 |
| -!- JimiDini_iphone [n=JimiDini@ip-83-149-3-230.nwgsm.ru] has quit ["Get Colloquy for iPhone! http://mobile.colloquy.info/"] | 15:17 | |
| X-Fade | It is not like we ask for your google account etc. | 15:17 |
| X-Fade | It is just a way for the user to prove he is who he says he is. | 15:18 |
| X-Fade | And to look up the correct accounts to match/merge | 15:18 |
| sopi | ok. what if an authentication fails, let's say i mistyped by talk password? | 15:18 |
| danielwilms | and when we do it in this way we dont have to think right now, how cas authenticates the user | 15:18 |
| X-Fade | Would make it easy to merge user foo in garage with bar in talk etc. | 15:19 |
| sopi | s/by/my | 15:19 |
| X-Fade | sopi: Then we would return with an error message? :) | 15:19 |
| -!- JimiDini_iphone [n=JimiDini@95-161-253-55.broadband.spb.TiERA.org] has joined #maemo-meeting | 15:19 | |
| danielwilms | ok...lets do it in this way | 15:20 |
| X-Fade | danielwilms: And how to generate cookies for each service. | 15:20 |
| X-Fade | danielwilms: So you are automatically logged in everywhere.. | 15:20 |
| danielwilms | yep | 15:20 |
| -!- JimiDini_iphone_ [n=JimiDini@83.149.3.230] has joined #maemo-meeting | 15:20 | |
| X-Fade | Which is another big problem, I think. | 15:20 |
| danielwilms | X-Fade wait | 15:20 |
| danielwilms | thats not right | 15:20 |
| danielwilms | sorry | 15:20 |
| danielwilms | I was wrong | 15:20 |
| * X-Fade is confused now ;) | 15:21 | |
| danielwilms | you are only automatically logged out, but not logged in...but you dont have to provide your credentials | 15:21 |
| danielwilms | at least you could implement it in this way | 15:21 |
| X-Fade | danielwilms: But if I click around in the main navigation, I jump between services. | 15:22 |
| X-Fade | It would make sense to stay logged in when going from m.o to talk etc. | 15:22 |
| danielwilms | this can be decided by the applications itself | 15:23 |
| X-Fade | No? | 15:23 |
| X-Fade | We have to do that? | 15:23 |
| danielwilms | depends on the implementation | 15:23 |
| sopi | but that would be the point of SSO, no? | 15:23 |
| X-Fade | A user should see everything as one website. | 15:24 |
| X-Fade | So only needing to login once. | 15:24 |
| danielwilms | yep...but when you want to have the control for the end-user where to login you could add a login link -> check the cookie -> and being logged in | 15:24 |
| X-Fade | Every service uses a different cookie. | 15:25 |
| X-Fade | So that is not going to work. | 15:25 |
| X-Fade | (on diffent hosts too) | 15:25 |
| X-Fade | Notice we have a hack for this problem for garage and maemo.org when you login to maemo.org | 15:26 |
| X-Fade | We post the login to garage too, so you are automatically logged in there too. | 15:26 |
| X-Fade | This is an ugly way to work around that problem. | 15:27 |
| danielwilms | it would...when you call the website...you can redirect to cas -> if you are looged in cas sends a ticket to the service -> the service validates it and está | 15:27 |
| danielwilms | otherwise you see the login page of cas and give you credentials | 15:27 |
| X-Fade | Ok, well that would work. | 15:27 |
| danielwilms | and if you want the control you put a link instead of redirecting directly | 15:28 |
| X-Fade | If the cas service for each host takes care of that, it is fine by me :) | 15:29 |
| danielwilms | it does | 15:29 |
| X-Fade | Great, problem solved! :) | 15:30 |
| danielwilms | :) | 15:30 |
| X-Fade | So only authentication implementation for every service and account merge then? | 15:30 |
| danielwilms | yep | 15:30 |
| danielwilms | and the last issue i can think of right now is who does what :) | 15:30 |
| danielwilms | i can take over gforge and make the wiki and cas nicer | 15:31 |
| danielwilms | could one of you guys have a look into midgard?? | 15:31 |
| X-Fade | danielwilms: JimiDini_iphone_ and bergie will probably do that part. | 15:32 |
| sopi | how about specifying 1st which data to store by CAS and make editable thru Midgard? | 15:32 |
| danielwilms | cas does not store anything | 15:32 |
| sopi | ok, LDAP then. sorry. | 15:32 |
| X-Fade | sopi: Good idea. | 15:32 |
| X-Fade | We might want to add that to the wiki. | 15:33 |
| danielwilms | first we can us ldap for the authentication | 15:33 |
| sopi | X-Fade: ok, who will do the draft? | 15:33 |
| X-Fade | For every service list what informtion is needed for the account. | 15:33 |
| sopi | X-Fade: ok. | 15:33 |
| danielwilms | that sonds good | 15:33 |
| danielwilms | I will extend the wiki page and you can put more information there | 15:34 |
| X-Fade | I can do a quick draft. | 15:34 |
| danielwilms | X-Fade ok | 15:34 |
| danielwilms | or like this | 15:34 |
| danielwilms | :) | 15:34 |
| bergie | BTW, sorry for idling... there is this other meeting happening in RL :-) http://www.qaiku.com/channels/show/iks-project/view/1de4abe461950f84abe11de86b8817366e5c66ec66e/ | 15:35 |
| X-Fade | danielwilms: Btw, you can use namespaces under Task:Single_sign-on. | 15:35 |
| danielwilms | bergie no problem :) | 15:35 |
| X-Fade | danielwilms: Like -> https://wiki.maemo.org/Task:Single_sign-on/Account_info_stored_in_ldap | 15:36 |
| danielwilms | ahhh...ok :) thx for the hint | 15:36 |
| X-Fade | That way we keep the info in one place. | 15:36 |
| danielwilms | yep...definitely better | 15:37 |
| X-Fade | And you get nice breadcrumbs. | 15:37 |
| danielwilms | sorry for the mess ;) | 15:37 |
| danielwilms | then I will put the status there and add the results from today | 15:37 |
| danielwilms | and X-Fade you make the draft? | 15:38 |
| X-Fade | I will collect information about what info is needed for every service. | 15:38 |
| danielwilms | great | 15:38 |
| X-Fade | And put that in the page. | 15:38 |
| -!- JimiDini_iphone_ [n=JimiDini@83.149.3.230] has quit [Read error: 110 (Connection timed out)] | 15:38 | |
| sopi | X-Fade: great! | 15:38 |
| sopi | how about deadlines? | 15:39 |
| danielwilms | good point | 15:39 |
| sopi | what are we supposed to achieve in the May sprint? | 15:39 |
| danielwilms | I'm on vaccations for 3 weeks from friday on | 15:39 |
| sopi | i guess it was to setup the SSO testing environment. | 15:40 |
| sopi | see: http://wiki.maemo.org/Maemo.org_Sprints/April_09 | 15:40 |
| danielwilms | yep...it is there...now we can start integrating | 15:40 |
| sopi | danielwilms: could you please update the sprint page? | 15:40 |
| danielwilms | sopi: will do that | 15:41 |
| danielwilms | do you think guys that we can reach a testable version beginning/mid august | 15:41 |
| danielwilms | ?? | 15:41 |
| -!- JimiDini_iphone [n=JimiDini@95-161-253-55.broadband.spb.TiERA.org] has quit [Read error: 113 (No route to host)] | 15:42 | |
| sopi | i think it is early to say, but let's see what we put to the June and July sprints. | 15:42 |
| danielwilms | ok...I will update my task and the rest you can decide in the next sprint meeting | 15:43 |
| danielwilms | i'm not in then | 15:43 |
| sopi | danielwilms: did you get account requests for the test environment? | 15:44 |
| danielwilms | yep...will add it afterwards | 15:44 |
| danielwilms | sopi...i will send you a mail | 15:44 |
| danielwilms | sooo...is there anything else to discuss | 15:45 |
| danielwilms | perhaps we could have one of these sessions in a couple of weeks again | 15:45 |
| danielwilms | i think it was really productive | 15:45 |
| sopi | yes, for the next session we should definitely know the application specific data and availability of people. | 15:46 |
| danielwilms | yep...sounds good | 15:46 |
| danielwilms | ok...then...thank you all for discussing here | 15:47 |
| danielwilms | the picture got clearer :) | 15:47 |
| sopi | danielwilms: thanks to you for the good 1st proposal and the test setup! | 15:47 |
| danielwilms | thx...and i like the task ;) | 15:48 |
| danielwilms | bye bye all! | 15:48 |
| sopi | see you! | 15:48 |
| X-Fade | Later. | 15:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
