Attendees: clsk, J_K9
Note: All timestamps in UTC+1 (British Summer Time).
Sep 09 16:57:52 <lancerr> Hi - Alan?
Sep 09 16:58:55 <clsk> hey
Sep 09 16:59:52 <lancerr> hey, thanks for joining me. I just want to get a good idea of where you're thinking of taking the directory module. :)
Sep 09 17:00:09 <lancerr> what role will it have when it is fully-functional and in what steps do you intend to expand it?
Sep 09 17:03:02 <clsk> give me a second. I have to finish something here real quick
Sep 09 17:03:02 <clsk> alright
Sep 09 17:03:02 <clsk> still there?
Sep 09 17:03:18 <lancerr> yes
Sep 09 17:03:27 <lancerr> no problem
Sep 09 17:03:34 <clsk> alright. Internet connection here is extremely slow
Sep 09 17:04:10 <clsk> well you said you had some ideas. Can you explain your ideas?
Sep 09 17:05:35 <clsk> hm. ello?
Sep 09 17:05:37 <lancerr> well, I was wondering how you were planning on implementing the role/workplace management and text-based auth systems. the reason I'm asking is because I think you have merged these two systems into the Directory module at the moment and, if that is how you intend to keep it, I would like to suggest a better system
Sep 09 17:05:41 <lancerr> sorry, long message :)
Sep 09 17:06:55 <clsk> hm yes I was planning on merging those together. Directory is kind of like a permission module
Sep 09 17:07:07 <clsk> Where you know what type of permissions users have in the different workplaces
Sep 09 17:07:38 <lancerr> ok - will the module's data be stored in the Directory.ptd file?
Sep 09 17:07:49 <clsk> for this users objects would have to be aware of workplace objects and viceversa
Sep 09 17:08:02 <lancerr> yes
Sep 09 17:08:40 <clsk> well.. like we said before we said before the interface will be flexible enough to where we can use plain text files, database or LDAP
Sep 09 17:08:53 <clsk> I implemented plain text first because it was the easiest.
Sep 09 17:09:14 <lancerr> yes, but I thought that was simply for authentication purposes and not to store the workplace and role data?
Sep 09 17:09:48 <clsk> but plain text won't be the most recommended implementation of course
Sep 09 17:09:48 <clsk> because it's not very secure
Sep 09 17:09:56 <lancerr> of course, i agree
Sep 09 17:10:39 <clsk> hm can you explain why you think it isn't a good way to do i?
Sep 09 17:11:12 <lancerr> but i'm just wondering how this is going to work. are you saying that the directory module will be able to interface with a DB or LDAP server instead of plain text, and that the workplace details, user list and relevant roles in the workplaces will be stored in whichever one is chosen? is LDAP suitable for that?
Sep 09 17:11:34 <clsk> correct
Sep 09 17:12:02 <clsk> LDAP could easily be used for that IMO.
Sep 09 17:12:18 <lancerr> ah, right. what i was thinking of was abstracting the authentication system from the role and workplace management one. my experience is limited to web apps, but what I did in my last one was:
Sep 09 17:12:27 <lancerr> one table to store user data for authentication
Sep 09 17:12:47 <lancerr> one table to store workplace data (name of workplace, description, creation date, list of Utilities etc)
Sep 09 17:13:09 <lancerr> (which *does not* include the data ADDED to the workplaces by its users, btw)
Sep 09 17:13:26 <lancerr> and one other table which describes a user's role in a workplace if they are a member of it
Sep 09 17:13:49 <clsk> hm that's kind of how I'm thinking of doing it.
Sep 09 17:14:08 <lancerr> the system would check if the logged in user had a role in (and thus access to) a workplace, and the relevant roles would be taken from the table
Sep 09 17:14:10 <clsk> not just data FOR authentication though.
Sep 09 17:14:14 <clsk> Just data in general.
Sep 09 17:14:18 <clsk> about the user
Sep 09 17:14:29 <lancerr> yes, such as the user's details, etc?
Sep 09 17:14:33 <clsk> descriptive data
Sep 09 17:14:35 <lancerr> yes
Sep 09 17:14:42 <clsk> such as name, etc…
Sep 09 17:15:05 <clsk> so we're pretty much thinking of the same thing.
Sep 09 17:15:11 <lancerr> excellent. I think we're both pretty clear about how to proceed then? unless you have any other ideas or thoughts to share I can begin writing the blueprint :)
Sep 09 17:15:22 <clsk> the Directory module will be flexible enough to where more stuff can be added at run-time though.
Sep 09 17:15:33 <lancerr> could you expand please?
Sep 09 17:15:45 <clsk> hm sure
Sep 09 17:16:31 <lancerr> e.g. what kind of stuff?
Sep 09 17:16:41 <clsk> instead of all the fields being hard-coded.
Sep 09 17:17:02 <clsk> we'd have something to where we can add what fields the directory module looks for
Sep 09 17:17:06 <clsk> in the database, plain text file, LDAP, or whatever is used.
Sep 09 17:17:55 <lancerr> ok, I think I understand what you mean. I don't want to keep you too long so perhaps we could discuss that in a bit more detail by email?
Sep 09 17:17:58 <clsk> with this even utilities could use the directory module to save utility-specific data.
Sep 09 17:18:25 <clsk> but that's something I'm still debating on. (if utilities would be able to do this)
Sep 09 17:18:35 <clsk> if you want.
Sep 09 17:18:40 <lancerr> oh, right. yes. we'd have to make sure the security module limits what can or cannot be edited by a certain subsystem though
Sep 09 17:18:46 <lancerr> *limit
Sep 09 17:18:47 <clsk> I don't really have anything to do now
Sep 09 17:18:51 <clsk> yea
Sep 09 17:18:54 <lancerr> ok
Sep 09 17:19:17 <clsk> hm I see beyonddc online. I'll ask him if he wants to join us
Sep 09 17:20:21 <lancerr> I think it would be good to offer Utility developers the ability to store Utility data in a variety of back-ends (such as DB, standard file-based system or SVN), so this could be used to store data in the DB.
Sep 09 17:20:23 <lancerr> sure
Sep 09 17:20:53 <clsk> is that ok?
Sep 09 17:20:53 <clsk> also another thing.
Sep 09 17:20:53 <clsk> What library should we use for database?
Sep 09 17:21:01 <lancerr> obviously, we'd have to keep track of which Workplaces were using which Utilities and where the data for each was stored
Sep 09 17:21:02 <clsk> oh yes.
Sep 09 17:21:08 <clsk> that's totallly different though.
Sep 09 17:21:34 <lancerr> so will the directory module not handle that?
Sep 09 17:21:43 <clsk> that's the storage module
Sep 09 17:22:12 <lancerr> yes, but shouldn't it be the directory module which keeps track of where the data is stored for each Utility used by each Workplace?
Sep 09 17:23:08 <lancerr> as for the DB library, how about sqlite? small, fast and a great project IMHO
Sep 09 17:23:44 <clsk> no
Sep 09 17:23:44 <clsk> directory module is to store data ABOUT users and workplaces.
Sep 09 17:23:44 <clsk> no. That's the storage module.
Sep 09 17:23:44 <clsk> the directory module is like an address book
Sep 09 17:23:44 <clsk> pretty much
Sep 09 17:23:45 <clsk> hm actually I was thinking more of a library that can support all kind of databases.
Sep 09 17:23:49 <clsk> or the most popular ones.
Sep 09 17:24:02 <lancerr> ok
Sep 09 17:24:04 <clsk> oracle, mysql, postgresql, microsoft sql server, etc…
Sep 09 17:24:06 <lancerr> do you have any in mind?
Sep 09 17:24:11 <lancerr> libraries, I mean
Sep 09 17:24:23 <clsk> there's a couple of good ones out there.
Sep 09 17:25:11 <clsk> hm yes, I was looking at one yesterday
Sep 09 17:25:11 <clsk> let see if I can find it now
Sep 09 17:25:18 <lancerr> the best thing to do then is to submit a list of them to the mailing list with personal opinions of each one.. vote for the best?
Sep 09 17:25:22 <lancerr> sure
Sep 09 17:25:50 <clsk> yes
Sep 09 17:26:13 <clsk> or we could write our own
Sep 09 17:26:33 <lancerr> true, but if we find one which suits are needs and can be quite easily implemented it would save time
Sep 09 17:26:40 <lancerr> *our needs
Sep 09 17:29:21 <clsk> http://sourceforge.net/projects/soci
Sep 09 17:29:21 <clsk> that was one ofthem
Sep 09 17:31:29 <clsk> http://soci.sourceforge.net/
Sep 09 17:31:29 <clsk> pretty straight foward if you know sql.
Sep 09 17:31:40 <lancerr> that library looks quite good - simple interface and supports quite a few DB servers (http://soci.sourceforge.net/)
Sep 09 17:31:53 <clsk> yus
Sep 09 17:33:00 <lancerr> great
Sep 09 17:35:07 <clsk> First I need to come up with a good interface for the directory base class.
Sep 09 17:35:24 <clsk> After that I'll get the database implementation working.
Sep 09 17:35:30 <lancerr> I agree. Let's work with the text-based back-end, at least for the first release
Sep 09 17:35:43 <clsk> I also got some work done on the network module.
Sep 09 17:37:15 <clsk> today that is
Sep 09 17:37:15 <clsk> I need to come up with a good way of parsing messages
Sep 09 17:37:15 <clsk> I have already have an idea of how to do it. Just have to find time.
Sep 09 17:37:15 <clsk> I think the network interface will stay pretty much the way it is right now with only a few changes.
Sep 09 17:37:28 <lancerr> ok, that's great
Sep 09 17:37:45 <clsk> If I get all of this working on the server side then I'll probably work on the same on the client side.
Sep 09 17:37:48 <lancerr> I assume the messages are in the same format as the one documented?
Sep 09 17:38:05 <lancerr> i agree - it shouldn't take much extra work to adapt the network module for the client
Sep 09 17:38:09 <clsk> they will be, yes.
Sep 09 17:38:34 <clsk> yea I should be able to borrow some of the code.
Sep 09 17:38:44 <lancerr> yes, sorry - I meant in the same format, but that's obviously a yes :)
Sep 09 17:39:09 <lancerr> great, good work! please commit it as soon as you can
Sep 09 17:39:29 <clsk> hm I think you should probably post a new recruitment message on sourceforge again. See if we can get a couple new developers.
Sep 09 17:39:54 <lancerr> ok. should i ask for any skills in particular? experience with certain libraries?
Sep 09 17:39:55 <clsk> Everybody seems inactive nowdays
Sep 09 17:40:31 <clsk> nah. Just as long as they have C++ experience we should be fine.
Sep 09 17:40:31 <clsk> for the GUI maybe wxwidgets experience
Sep 09 17:40:34 <lancerr> yes, but i think the majority of them are waiting for the pace to pick up a bit, which will happen as the more confident developers like yourself write the initial code
Sep 09 17:40:44 <lancerr> ok
Sep 09 17:40:54 <clsk> but everything else is pretty straight-foward.
Sep 09 17:41:18 <lancerr> I think Daryl's working on that with Thurston, actually, so I'll just ask for the first part then (although experience with wxWidgets is an added advantage :)
Sep 09 17:41:40 <clsk> I'm going to start taking my laptop to work and hopefully get some coding done.
Sep 09 17:42:11 <lancerr> thank you, that'll be great. i'll get working on the blueprints to make it easier for the newcomers to settle in and get writing code asap
Sep 09 17:42:31 <lancerr> oh, wow
Sep 09 17:42:32 <lancerr> ok
Sep 09 17:42:34 <clsk> nice
Sep 09 17:42:43 <clsk> that's where I suck. the documentation
Sep 09 17:42:53 <lancerr> hehe, no probs - it's my speciality ;)
Sep 09 17:43:11 <lancerr> not that I'm bad with code, I just find that it takes me time to learn new programming languages
Sep 09 17:43:32 <lancerr> i've never coded for the desktop, that's why :)
Sep 09 17:43:39 <clsk> yea I know what you mean.
Sep 09 17:44:43 <clsk> oh one more thing
Sep 09 17:44:46 <lancerr> sure
Sep 09 17:44:48 <clsk> are we going to use the GPL?
Sep 09 17:44:52 <lancerr> i think so, yes
Sep 09 17:45:02 <clsk> hm ok.
Sep 09 17:45:11 <lancerr> unless you want to suggest another licence?
Sep 09 17:45:23 <lancerr> of course i will put it to the developers and have a vote
Sep 09 17:45:31 <clsk> not really. I'm not very picky about libraries.
Sep 09 17:45:40 <lancerr> but I thought the GPL was the most appropriate, having considered several OSI-approved licences
Sep 09 17:45:44 <clsk> yes, that's probably better. Some people are picky about that.
Sep 09 17:45:56 <lancerr> yes, sure
Sep 09 17:46:24 <lancerr> i will probably call a conference next week for all developers too, so we can discuss that then.
Sep 09 17:46:31 <clsk> I personally don't mind.
Sep 09 17:46:31 <clsk> I agree.
Sep 09 17:46:31 <clsk> it's probably the most appropiate for our case.
Sep 09 17:46:37 <lancerr> yes
Sep 09 17:46:56 <clsk> Just ask for a vote on the mailing list. I think we should decide on one soon since we now have code in the repository.
Sep 09 17:47:19 <lancerr> yes, definitely. I will email the list tonight about that.
Sep 09 17:48:03 <clsk> oh ok
Sep 09 17:48:03 <clsk> that'd work too.
Sep 09 17:48:03 <clsk> do you want to discuss anything else?
Sep 09 17:48:08 <lancerr> do you want to mail the list about the possible DB libraries? i think it's best to leave that in the back of our minds until we begin working on the next release though, as we agreed it's too early to work on the db interface
Sep 09 17:48:16 <lancerr> apart from that, nothing else. :)
Sep 09 17:48:45 <clsk> hm. I was actually thinking of implementing that now. But we could leave it for the next release.
Sep 09 17:49:12 <clsk> actually, yes. Lets just leave it for the next release.
Sep 09 17:49:27 <clsk> That way I can concentrate on the network better.
Sep 09 17:49:27 <lancerr> oh, really? well, unless you have something else more important to work on which you would like to do then you're free to do it :)
Sep 09 17:49:30 <lancerr> ok#
Sep 09 17:51:09 <clsk> well
Sep 09 17:51:18 <clsk> I have to go call the g/f
Sep 09 17:51:20 <lancerr> ok, well thanks a lot for joining me here - I'm very pleased with what we've accomplished! I'm sure we'll talk soon on the mailing list :)
Sep 09 17:51:31 <lancerr> talk to you soon
Sep 09 17:51:53 <clsk> np. good night
Sep 09 17:51:59 <lancerr> goodnight!
Discussion