Developer Meeting 21/10/2007 21:00 UTC
Attendees: akar_naveen (Naveen), beyonddc, clsk, fred (ifdef5), J_K9
Note: All timestamps in UTC+2 (Central European Summer Time).
Oct 21 23:10:03 <J_K9> ok, we should probably start
Oct 21 23:10:35 <clsk> hm yea
Oct 21 23:10:53 <clsk> Hopefully Naveen will come to the computer before we're done.
Oct 21 23:11:02 <clsk> Fred: still there?
Oct 21 23:11:02 <J_K9> this is a general developer meeting which was originally intended to introduce Fred and Naveen to the project as well as discuss roles and a module, but Naveen and David may still join us
Oct 21 23:11:40 <ifdef5> yes, sorry
Oct 21 23:11:44 <J_K9> no problem
Oct 21 23:12:06 <J_K9> Fred, did you have a chance to look through the documentation?
Oct 21 23:12:22 <ifdef5> i saw it as of last week
Oct 21 23:12:45 <J_K9> ah ok, so I presume you have a rough idea about the different layers and modules?
Oct 21 23:13:14 <ifdef5> yeah
Oct 21 23:13:20 <J_K9> great
Oct 21 23:13:35 <ifdef5> is there user oriented requirements; use cases or are you just assuming “groove” like
Oct 21 23:14:03 <clsk> I think there is some type of use case on the wiki.
Oct 21 23:14:08 <J_K9> we don't have specific use cases but we are aiming for a groove-like system
Oct 21 23:14:12 <clsk> Just something general though. Nothing specific.
Oct 21 23:14:19 <J_K9> the aim is to allow for improved collaboration in the workplace
Oct 21 23:14:29 <ifdef5> ok
Oct 21 23:14:44 <clsk> I think the main thing is integrated utilities
Oct 21 23:14:47 <J_K9> so we found it hard to make use cases without excluding the project's other significant features
Oct 21 23:14:55 <J_K9> yes - and its extensibility
Oct 21 23:15:00 * beyonddc (n=David_Ch@c-71-233-214-198.hsd1.ma.comcast.net) has joined #mira
Oct 21 23:15:10 <beyonddc> Hey guys
Oct 21 23:15:11 <clsk> hey devid
Oct 21 23:15:14 <J_K9> David, thanks for joining us! we thought you weren't going to make it ;)
Oct 21 23:15:26 <beyonddc> 
… yea, I rushed home. I was outside.
Oct 21 23:15:26 <J_K9> we've only just started
Oct 21 23:15:30 <J_K9> haha, thanks
Oct 21 23:15:45 <beyonddc> Hey Stefan. 
Oct 21 23:16:04 <ifdef5> ifdef = fred; hi david
Oct 21 23:16:05 <clsk> ifdef5: Right now we're more focused on the core than on the utilities.
Oct 21 23:16:22 <J_K9> we're working from the bottom up (ref: layers diagram)
Oct 21 23:16:26 <beyonddc> Hi Fred
Oct 21 23:16:30 * clsk = Alan
Oct 21 23:16:45 <ifdef5> utilities = tools (groove world) ?
Oct 21 23:16:51 <J_K9> I think so
Oct 21 23:17:05 <J_K9> Utilities are plugins in Workplaces - are those called Tools in groove?
Oct 21 23:17:13 <ifdef5> yes
Oct 21 23:17:20 <J_K9> ah, yep - that's it. yes, a similar idea
Oct 21 23:17:40 <J_K9> although we plan to have a self-updatable system in the future and a much-improved Utility management system
Oct 21 23:17:42 <clsk> so yea
Oct 21 23:17:48 <J_K9> but more on that at a later date
Oct 21 23:18:05 <J_K9> should we discuss one of the core modules? unless Fred has any other questions? :)
Oct 21 23:18:08 <beyonddc> Just in case you couldn't find it. This is the URL to the layers diagram that we drafted out awhile back. http://miragroupware.org/wiki/doku.php/development/blueprints/layers_diagram
Oct 21 23:19:02 <clsk> The way we've planned it is eveything the user does on a workplace is done with an utility.
Oct 21 23:19:02 <clsk> We should probably answer any questions that he might have.
Oct 21 23:19:21 <J_K9> I agree
Oct 21 23:20:10 <J_K9> We also have a more granular roles system, so a Workplace's Project Manager can define new roles and apply them to the Workplace's members accordingly
Oct 21 23:20:25 <J_K9> (by 'have' I mean 'have plans for' :)
Oct 21 23:20:25 <clsk> Do you have any questions about the general design and how we want mira work?
Oct 21 23:20:34 <ifdef5> does the security layer enforce identity?
Oct 21 23:20:43 <clsk> no
Oct 21 23:20:59 <clsk> that's the directory layer
Oct 21 23:21:14 <ifdef5> i guess i should ask is everyone ben a groove user at some point, so if we make groove analogies everyone knows about them?
Oct 21 23:21:25 <J_K9> I have used Groove in the past
Oct 21 23:21:29 <beyonddc> No, I never been a groove user.
Oct 21 23:21:45 <clsk> The directory layer handles identity of users and workplaces. Also stores data about the user.
Oct 21 23:21:45 <clsk> I haven't.
Oct 21 23:22:00 <clsk> I've read about how it works though.
Oct 21 23:22:50 <J_K9> For front-end references, the Mira mock-ups may help though: http://miragroupware.org/screenshots.php
Oct 21 23:23:32 <clsk> I'll be back in a second
Oct 21 23:23:42 <J_K9> sure
Oct 21 23:24:51 <beyonddc> Sorry I was late, but it feels like we're just all over everything right now. What's the main topic for today?
Oct 21 23:25:20 <J_K9> Alan and David please correct me if I'm wrong, but the role of the security layer is for input verification and to ensure that the upper layers are accessing the modules and data below that they are allowed to
Oct 21 23:25:47 <J_K9> David - Fred is a new developer to the project, so we're just answering any questions he has on the system
Oct 21 23:26:15 <J_K9> after that, we will discuss a module so that I can draft up another specification
Oct 21 23:26:57 <ifdef5> i'll just lurk the docs and source for awhile - i'm glad to do pretty much anything.
Oct 21 23:26:58 <beyonddc> Yes Max, that's correct.
Oct 21 23:27:20 <J_K9> Fred, how is the OpenBSD driver going?
Oct 21 23:27:52 <clsk> J_K9: That's right. We don't know how exactly it's going to work. The plan is to have the security layer between the user and the resources the framework provides to ensure people don't access resources they're not supposed to access.
Oct 21 23:27:57 <ifdef5> opensolaris - i had to cancel a demo, it isn't quite stable enough to ship, but its real close
Oct 21 23:28:04 <J_K9> ah, ok
Oct 21 23:28:22 <clsk> What's the driver you're working on for?
Oct 21 23:28:26 <J_K9> clsk - thanks for clarifying
Oct 21 23:28:58 <ifdef5> it's a driver sitting between an ipsec encryption engine and a userland policy engine
Oct 21 23:29:20 <ifdef5> policy manager
Oct 21 23:29:41 <clsk> oh
Oct 21 23:29:48 <J_K9> so you are quite involved in security?
Oct 21 23:30:21 <ifdef5> i've done lots of ike, ipsec, tls/ssl etc.
Oct 21 23:30:22 <beyonddc> I don't know a lot about ipv6.
Oct 21 23:30:36 <beyonddc> ipsec is part of ipv6, right?
Oct 21 23:31:01 <J_K9> no
Oct 21 23:31:06 <ifdef5> ipv6 uses ipsec
Oct 21 23:31:06 <clsk> hm no
Oct 21 23:31:17 <ifdef5> for encryption
Oct 21 23:31:34 <beyonddc> o
Oct 21 23:31:57 <clsk> so are you working for sun or are you just doing it for fun?
Oct 21 23:32:43 <ifdef5> my old startup drafted me to moonlight the driver - they have a customer who uses sun.
Oct 21 23:33:18 <ifdef5> cipheroptics.com
Oct 21 23:34:08 <J_K9> while we're on the topic of network encryption, we do plan on enabling data transmission encryption by default in Mira
Oct 21 23:34:40 <Naveen> hi all, I am back….sorry for being late
Oct 21 23:34:52 <ifdef5> i think comm encryption is one of the most important features…
Oct 21 23:34:53 <J_K9> Hi Naveen - no problem!
Oct 21 23:35:00 <J_K9> likewise
Oct 21 23:35:13 <ifdef5> so many groups want provable privacy
Oct 21 23:35:42 <J_K9> what do you think is the best method of doing so? tunnelling over SSH?
Oct 21 23:36:55 <ifdef5> since you don't really have to interoperate, as long as encryption is strong enough, the app may not matter
Oct 21 23:37:03 <ifdef5> app → protocol
Oct 21 23:38:02 <ifdef5> anyway, it should be more or less transparent to the end user
Oct 21 23:38:09 <J_K9> so what you're saying is either encrypting the data itself or the packets?
Oct 21 23:38:09 <clsk> hm well I was thinking of using ssl
Oct 21 23:38:19 <clsk> since it's implemented in asio
Oct 21 23:38:30 <J_K9> it is? ah..
Oct 21 23:39:05 <ifdef5> one nice thing about groove is firewall transparency…
Oct 21 23:39:30 <clsk> true
Oct 21 23:39:48 <J_K9> in what sense - no port forwarding required?
Oct 21 23:40:01 <ifdef5> that's one for sure.
Oct 21 23:40:18 <ifdef5> i' think they used a stun service for connecting all of their clients
Oct 21 23:40:52 <J_K9> ah
Oct 21 23:40:53 <ifdef5> if you can do that with tls, that would be a nice way to do zero config for networkd connections
Oct 21 23:40:56 <clsk> That was something I was thinking about the other day actually.
Oct 21 23:41:30 <J_K9> did you come up with a rough plan, clsk?
Oct 21 23:42:45 <clsk> well I'm not sure exactly how it works. But I'm guess that since all users have to connect to the server authentication it should be possible to do.
Oct 21 23:42:49 <clsk> not really.
Oct 21 23:43:37 <J_K9> actually, Fred's probably right - we probably will need to use STUN in order to allow the clients to connect to each other if they are NAT'd, correct?
Oct 21 23:43:44 <ifdef5> http://en.wikipedia.org/wiki/STUN
Oct 21 23:43:59 <ifdef5> NAT is the ugliest problem, I think
Oct 21 23:44:53 <ifdef5> i think zero config for most things is needed to make Mira as simple as other web services
Oct 21 23:45:29 <clsk> hm anybody knows how (IRC) DCC works? or instant messaging systems file share works?
Oct 21 23:45:38 <J_K9> well, distributed data transfer may also be a problem… considering the diverse nature of the storage mechanism (utilities can store data on the filesystem, in a DB or in plaintext files), we'll have to work out a way of making a client download the data in equal parts from the other online clients
Oct 21 23:46:00 <J_K9> shouldn't we be looking at a BitTorrent-like system rather than IM-like?
Oct 21 23:46:49 <ifdef5> isn't the problem w/ bt the fact that you need lots of seeds to be effective?
Oct 21 23:47:00 <ifdef5> efficient?
Oct 21 23:47:11 <J_K9> true, it doesn't work very efficiently with few seeds
Oct 21 23:47:26 <J_K9> but i was thinking of a hybrid BitTorrent/standard download system
Oct 21 23:47:54 <J_K9> whereby equal proportions of data are downloaded from different clients rather than the data itself being split
Oct 21 23:48:20 <ifdef5> what if the two aren't sync'd?
Oct 21 23:48:25 <clsk> well only plain text and versioned files will be distributed.
Oct 21 23:48:25 <clsk> data on a database system will probably be stored on the server only.
Oct 21 23:48:25 <clsk> I see. Never heard of the term STUN.
Oct 21 23:48:25 <clsk> But that's how I thought it worked.
Oct 21 23:48:48 <J_K9> ifdef5: the server will know that and will tell the client which needs to be sync'd which clients are up-to-date
Oct 21 23:50:23 <J_K9> clsk - ah, ok. so if Utilities store data in a “DB”, could that be converted to an XML file for the clients?
Oct 21 23:50:37 <clsk> ifdef5: The way we're thinking of it working is: Server tells client A he needs to update a file. Client A requests sync. Server checks from the users online who has updated files and asks those clients if they can send the data to Client A.
Oct 21 23:50:42 <clsk> So the server pretty much schedules everything.
Oct 21 23:51:21 <ifdef5> question - is all data distributed, or is some stored centrally?
Oct 21 23:51:52 <clsk> We're thinking of both. Have a copy stored in the server too.
Oct 21 23:51:59 <J_K9> all Workplace-related data is distributed (according to each Client's privileges, of course)
Oct 21 23:52:10 <J_K9> but as clsk said, the server also keeps a copy (the most up-to-date version)
Oct 21 23:52:39 <ifdef5> does the server do diffs and merging for the clients?
Oct 21 23:52:49 <clsk> and if there are on clients online the server can also send to a client that needs an update.
Oct 21 23:53:21 <J_K9> ifdef5: if the updates are mergeable, yes. if not, the conflict is flagged and must be resolved by a Workplace member
Oct 21 23:56:33 <Naveen> how does the server know that client has changed an object
Oct 21 23:56:57 <clsk> The client sends changes to the server automatically.
Oct 21 23:57:01 <J_K9> there is a Mira daemon/service running on the client which detects changes to Workplace objects
Oct 21 23:57:12 <clsk> if they're not online they will as soon as they authenticate with the server.
Oct 21 23:57:59 <Naveen> is the entire change transmitted or just a flag indicating the change
Oct 21 23:58:19 <Naveen> I guess the entire change
Oct 21 23:58:21 <J_K9> if the file is mergeable, a diff of the file is transmitted
Oct 21 23:58:23 <clsk> the entire change is transmitted
Oct 21 23:58:24 <J_K9> if not, the entire file
Oct 21 23:58:30 <clsk> since the server keeps a copy of all files
Oct 21 23:58:31 <Naveen> for the server to have the up-tp date
Oct 21 23:58:40 <J_K9> correct
Oct 21 23:59:49 <Naveen> and when the server is down, these changes are stored in a sort of log
Oct 22 00:00:14 <J_K9> yes, just as if the client were offline
Oct 22 00:00:42 <J_K9> the changes are logged by the daemon until both the client and server are online
Oct 22 00:00:43 <clsk> hm well the server shouldn't be down.
Oct 22 00:00:51 <clsk> But all changes are saved to the filesystem
Oct 22 00:00:55 <J_K9> hehe, that's the plan!
Oct 22 00:01:23 <clsk> if the server is down then clients will be offline.
Oct 22 00:01:31 <clsk> because they can't authenticate
Oct 22 00:01:36 <J_K9> indeed
Oct 22 00:01:39 <clsk> so as far as the client knows they're offline.
Oct 22 00:01:51 <clsk> or
Oct 22 00:02:00 <Naveen> how about allowing communiation between already authenticated clients
Oct 22 00:02:10 <clsk> goes
Oct 22 00:02:33 <Naveen> with reduced funtionality
Oct 22 00:03:03 <Naveen> like no file syncs
Oct 22 00:03:05 <J_K9> but for that to work the clients would have to be online and authenticated at the time the server went down, right? if not they would not be able to locate each other
Oct 22 00:03:07 <Naveen> only IM
Oct 22 00:03:18 <Naveen> right
Oct 22 00:03:27 <J_K9> that is a good point
Oct 22 00:03:44 <clsk> communication between already authenticated clients is scheduled through the server
Oct 22 00:03:44 <clsk> so, same thing applies
Oct 22 00:03:44 <clsk> hm we could probably do that too.
Oct 22 00:03:44 <clsk> yea. We could do that.
Oct 22 00:03:50 <J_K9> it would be a rare case, but that could be an interesting thing to implement in the future
Oct 22 00:04:33 <Naveen> when the server is down no new clients can be added
Oct 22 00:04:43 <J_K9> that's right
Oct 22 00:04:50 <Naveen> as you said in forum…more availability
Oct 22 00:05:10 <J_K9> true
Oct 22 00:05:30 <J_K9> we could also allow for redundancy in the future in a similar way to MySQL master/slave servers
Oct 22 00:06:03 <J_K9> so in case the master Mira server went down, there would be a backup to which the clients could connect (and whose IP address they would know thanks to the master server)
Oct 22 00:06:59 <clsk> yes, that's something I've thought about. Backup servers.
Oct 22 00:07:23 <J_K9> but that could be something to implement at a later date - for now, we should focus on getting the core client-server functionality in place
Oct 22 00:07:31 <clsk> right
Oct 22 00:07:37 <ifdef5> seems like more p2p would be better - just enough server to glue the peers together
Oct 22 00:07:51 <Naveen> right
Oct 22 00:08:12 <J_K9> ifdef5: that's the intention, but the user/enterprise would have to have at least one Mira server
Oct 22 00:08:35 <J_K9> the reason we cannot use a Groove-like setup is that, as an Open Source project, we don't have the resources to have centralised servers
Oct 22 00:08:42 <ifdef5> or a public mira server somewhere in the cloud?
Oct 22 00:08:57 <ifdef5> ok - i understand
Oct 22 00:09:02 <J_K9> I don't think that's a problem though - this model is probably more convenient for enterprises, as they can control the servers and know that their data is secure
Oct 22 00:09:14 <clsk> If we were to get donations in the future, then yes.
Oct 22 00:09:26 <J_K9> it would require quite an internal overhaul though
Oct 22 00:09:35 <J_K9> but yes, that would be great
Oct 22 00:09:58 <J_K9> then, if a Mira server were to go down, the clients could still connect to each other without a problem
Oct 22 00:11:57 <clsk> hm
Oct 22 00:12:37 <J_K9> clsk - do you want to add something? or shall we discuss the network module's other requirements?
Oct 22 00:13:17 <clsk> not really.
Oct 22 00:14:01 <clsk> Just curious about what part of the project would Fred and Naveen like to work on.
Oct 22 00:14:01 <clsk> also if they have any other questions about the design.
Oct 22 00:14:24 <clsk> or have something to add to it.
Oct 22 00:14:30 <ifdef5> whatever it takes to get to v0.1 ;)
Oct 22 00:14:39 <Naveen> same here
Oct 22 00:14:44 <J_K9> hehe, that's the spirit :)
Oct 22 00:15:14 <ifdef5> what do you guys feel like are the spots that need some attention?
Oct 22 00:15:26 <J_K9> do you have any particular preferences though? some modules are more challenging than others, e.g. the storage module
Oct 22 00:15:48 <Naveen> I am not strong at security
Oct 22 00:16:12 <Naveen> I can start with db or networking
Oct 22 00:16:24 <clsk> Right now the client-side networking.
Oct 22 00:16:32 <ifdef5> is there anyone working in the security layer now?
Oct 22 00:16:33 <clsk> I'm currently working on the server-side.
Oct 22 00:16:41 <Naveen> or even wxwidgets
Oct 22 00:17:19 <J_K9> Naveen, you could help Daryl with the client's GUI, or if not you could work on the DB or Storage modules?
Oct 22 00:17:22 <clsk> Fred: Not at the moment. We don't really know how that's going to work yet. We plan the security layer to sit on top of the Utility layer.
Oct 22 00:17:46 <J_K9> clsk: don't you mean *underneath* the Utility layer?
Oct 22 00:18:05 <clsk> hm.
Oct 22 00:18:09 <clsk> Right.
Oct 22 00:18:44 <J_K9> that way it can verify whatever actions the Utility layer, or the user is trying to commit
Oct 22 00:18:52 <clsk> The security layer is in between the Utility layer and all the other resources (network, directory, storage, etc…)
Oct 22 00:19:35 <J_K9> we also have to take into account that, as Mira's Utility architecture is extensible, we're going to have to place strong restrictions on Utility calls to the lower modules which will need to be handled by the security layer
Oct 22 00:20:22 <clsk> right.
Oct 22 00:21:05 <clsk> Right now I think the most importat thing to get to alpha (I'll talk about this later) is to get the GUI layer to a working stage to where it can interact with other things.
Oct 22 00:21:07 <J_K9> so the security layer is also going to be quite tough, but I think we should leave that until the lower level modules (directory, DB, storage, network, etc) have been completed
Oct 22 00:21:17 <clsk> Also get the client-side networking started
Oct 22 00:21:50 <Naveen> the gui module communicates with the networking and storage layers, right
Oct 22 00:22:00 <Naveen> i.e., without the security
Oct 22 00:22:05 <clsk> right
Oct 22 00:22:34 <J_K9> yes - actually, we need to make a different layer diagram for the client. thanks for the reminder
Oct 22 00:22:35 <Naveen> so an API is needed for access to these modules
Oct 22 00:22:49 <clsk> right
Oct 22 00:22:55 <clsk> well each module has an API.
Oct 22 00:22:59 <clsk> some type of API
Oct 22 00:23:10 <clsk> for other modules to access.
Oct 22 00:23:27 <J_K9> for the client's networking code, we can use clsk's existing server-side networking code but adapt it accordingly
Oct 22 00:24:54 <clsk> There another thing. On our first meeting we said we wanted the network layer to be flexible enough to where we can change to a different network library,
Oct 22 00:24:56 <Naveen> I believe a standard messaging protocal between layers would be helpful while developing them
Oct 22 00:25:05 <clsk> That's possible with what I've done so far.
Oct 22 00:25:36 <clsk> Naveen: There's a protocol document on the wiki with the basic messages.
Oct 22 00:25:44 <Naveen> clsk - thanks, I will see the code
Oct 22 00:25:49 <clsk> It doesn't include messages for utilities interaction though.
Oct 22 00:26:08 <J_K9> clsk - but is that for inter-layer messages? I thought that only applied to network messages i.e. client-server and client-client?
Oct 22 00:26:11 <clsk> We also want to accomplish the same for the directory module.
Oct 22 00:26:21 <J_K9> (https://blueprints.launchpad.net/mira/+spec/net-protocols)
Oct 22 00:26:33 <clsk> so that we can use different back-ends for storing information such as Database and LDAP.
Oct 22 00:26:44 <clsk> Right now I'm working on a XML implementation.
Oct 22 00:27:05 <clsk> I'll start on the Database and LDAP after the basic interface is done.
Oct 22 00:28:06 <clsk> Also what I wanted to say was that I'm thinking of setting goals for our alpha. As what we need to have implemented before we consider that we've reached an alpha version.
Oct 22 00:28:39 <J_K9> Good idea. we can use the specifications to help (although we do only have about two atm… 
Oct 22 00:28:44 <Naveen> that would be very useful
Oct 22 00:28:54 <clsk> Which is actually not a lot. Just basic communication between client/server. Basic GUI infrastructure. Basic directory (authentication, querying, etc…)
Oct 22 00:29:31 <clsk> then I think we should leave utilities for either beta, or a second alpha since that's a wide topic and something that will take to implement.
Oct 22 00:29:33 <Naveen> the utilities we want to include initially
Oct 22 00:29:40 <J_K9> Utilities? we don't need to have the extensible structure, but perhaps the filesharing Utility integrated?
Oct 22 00:29:55 <clsk> hm
Oct 22 00:30:02 <clsk> ok then.
Oct 22 00:30:05 <clsk> that too
Oct 22 00:30:15 <J_K9> if we included one Utility for the alpha release, that would show that the entire system works as it should
Oct 22 00:30:33 <Naveen> I agree
Oct 22 00:30:35 <J_K9> we can then abstract the filesharing Utility from the Utility API in later releases and make more Utilities
Oct 22 00:30:35 <clsk> right
Oct 22 00:30:42 <clsk> sounds fair
Oct 22 00:30:46 <J_K9> ok
Oct 22 00:31:36 <clsk> hm
Oct 22 00:31:45 <Naveen> so alpha is going to have one utility - file sharing
Oct 22 00:31:55 <clsk> correct.
Oct 22 00:32:11 <J_K9> aye
Oct 22 00:32:28 <Naveen> no security
Oct 22 00:32:49 <Naveen> and version control?
Oct 22 00:32:49 <clsk> hm we could implement some type of security. Specially since Fred wants to work on the security layer.
Oct 22 00:32:55 <J_K9> hmm..
Oct 22 00:33:03 <clsk> Probably no version control for alpha.
Oct 22 00:33:17 <clsk> just replaceable files.
Oct 22 00:33:20 <J_K9> yes, I don't think security should be an afterthought - we can have a basic but functional security layer
Oct 22 00:33:22 <ifdef5> could… but wouldn't want to do something now that has to be undone later
Oct 22 00:33:39 <clsk> right
Oct 22 00:34:00 <J_K9> I agree about no version control for alpha - a bit too complicated and we need to read up on SVN's API if that's what we want to use for it (discuss when the time comes)
Oct 22 00:34:26 <ifdef5> security for mira is going to be huge - it should touch everything, so we probably want everyone to agree with the philosophy
Oct 22 00:34:47 <ifdef5> not to forget - once you add the security it will be a lot harder to debug
Oct 22 00:35:15 <J_K9> yes, as we said it's going to be very granular, so ifdef5 is right… so should we add the security layer in the alpha release or later?
Oct 22 00:35:31 <clsk> I agree
Oct 22 00:35:31 <clsk> exactly
Oct 22 00:35:36 <clsk> later
Oct 22 00:36:11 <J_K9> ok
Oct 22 00:36:18 <beyonddc> umm
Oct 22 00:36:39 <beyonddc> I think we need to have some security in alpha release.
Oct 22 00:36:41 <Naveen> me too later, but with a knowledge where it would fit when it's brought in
Oct 22 00:36:56 <clsk> right
Oct 22 00:36:56 <clsk> hm
Oct 22 00:37:34 <beyonddc> It's hard to integrate security.
Oct 22 00:37:53 <beyonddc> hard to integrate security at the middle, that's what I meant.
Oct 22 00:38:09 <clsk> well security within each module will be done when the module is being built.
Oct 22 00:38:21 <clsk> But the external security module will be something different.
Oct 22 00:39:47 <beyonddc> so let me just rephrase what you said to make sure I understand. You mean when we stat working on a module we can question ourselve what we want for security on that module and then build that security into it?
Oct 22 00:40:08 <ifdef5> security: identity, file encryption, permissions, net encryption, authentication,etc…
Oct 22 00:40:16 <clsk> hm not really.
Oct 22 00:40:30 <J_K9> beyonddc: well, inbuilt security should be defined in the module's specification
Oct 22 00:40:38 <ifdef5> at some point, probably need to write a short on what security means to mira
Oct 22 00:40:42 <J_K9> so it's not necessarily thought of as the code is written
Oct 22 00:40:45 <J_K9> true
Oct 22 00:40:47 <clsk> Fred: The security layer will take care more of permission than anything else.
Oct 22 00:41:09 <clsk> Authentication is done by the Directory layer, file encryption will be done by the storage module.
Oct 22 00:41:45 <ifdef5> ok
Oct 22 00:42:38 <J_K9> so the security layer incorporates the roles system? is that both the Server and Workplace roles?
Oct 22 00:42:38 <ifdef5> dave's right though - the day you cutover from no file encryption to encryption will be a painful one.
Oct 22 00:42:40 <clsk> beyonddc: What I meant was that each module has the responsibility to have security built into it. The security layer will take care of permissions. Who can access what resources.
Oct 22 00:42:55 <ifdef5> for example
Oct 22 00:43:20 <J_K9> ifdef5: I think we need to make file encryption on the *client side* optional, but mandatory on the server side
Oct 22 00:44:11 <ifdef5> ok
Oct 22 00:44:26 <beyonddc> Well, my main point is we need to think about security from day one. I am in a project right now at work that they want to implement security during release 5 of the development.
Oct 22 00:44:35 <beyonddc> All I can say is pain pain pain and more pain.
Oct 22 00:44:36 <beyonddc> eh.
Oct 22 00:44:37 <J_K9> it should still be implemented, but it's important to leave it open to the user
Oct 22 00:44:49 <J_K9> lol beyonddc
Oct 22 00:44:49 <clsk> well hmm.. Encryption isn't really done on the security layer.
Oct 22 00:45:12 <clsk> security layer is more of a permission layer.
Oct 22 00:45:12 <clsk> Perhaps we should rename it.
Oct 22 00:45:21 <J_K9> clsk - as you said before, it's done by the storage layer
Oct 22 00:45:24 <beyonddc> I need to brb.
Oct 22 00:45:27 * beyonddc (n=David_Ch@c-71-233-214-198.hsd1.ma.comcast.net) has left #mira
Oct 22 00:45:30 <J_K9> I think so. How about Privileges Layer?
Oct 22 00:45:46 <J_K9> (we need to distinguish between privileges and permissions)
Oct 22 00:46:00 * beyonddc (n=beyonddc@c-71-233-214-198.hsd1.ma.comcast.net) has joined #mira
Oct 22 00:46:04 <Naveen> or authentication layer
Oct 22 00:46:07 <beyonddc> back
Oct 22 00:46:22 <clsk> Authentication is done through the Directory layer.
Oct 22 00:46:29 <clsk> So that can actually be confusing.
Oct 22 00:46:31 <J_K9> Naveen: that might be confusing though, because the Directory module handles authentication (maybe we should rename that layer too?)
Oct 22 00:46:54 <Naveen> ok
Oct 22 00:46:59 <clsk> well directory layer takes care of more than just permission
Oct 22 00:47:19 <clsk> or maybe we should move authentication to the security layer?
Oct 22 00:47:57 <J_K9> no, I think it's best to keep it lower down in the directory layer
Oct 22 00:48:01 <ifdef5> groove defines a number of roles, each with specific set of permissions. The manager of the workspace can invite a user and assign a role to them. (manager, user, guest)
Oct 22 00:48:16 <J_K9> but as you said, the Directory layer does do more than authentication
Oct 22 00:48:23 <clsk> right
Oct 22 00:48:24 <J_K9> ifdef5: we're going to make that even more granular
Oct 22 00:48:30 <ifdef5> ok
Oct 22 00:48:31 <clsk> the directory layer stores information about roles.
Oct 22 00:48:40 <J_K9> we intend to allow the PM to customise the roles himself/herself
Oct 22 00:48:55 <J_K9> the security layer enforces those roles
Oct 22 00:49:03 <clsk> right
Oct 22 00:49:26 <clsk> security layer is more like an enforcer.
Oct 22 00:49:33 <clsk> the information is elsewhere. The security layer gathers information and enforces rules.
Oct 22 00:49:35 <clsk> pretty much
Oct 22 00:49:49 <J_K9> sounds like a good design to me
Oct 22 00:50:56 <ifdef5> are those responsibilities listed somewhere for each of the layers. soory, if it is and i just haven't seen it yet
Oct 22 00:51:29 <clsk> What responsibilities? like what each layer stores?
Oct 22 00:51:52 <J_K9> ifdef5: do you mean if the roles can be configured so that privileges can be defined for elements and actions in a Utility within a Workplace?
Oct 22 00:51:53 <clsk> or what each layer does
Oct 22 00:52:06 <ifdef5> like the directory layer will <x>; x = store info about roles
Oct 22 00:52:42 <clsk> hm
Oct 22 00:52:42 <clsk> I think Max put something on the wiki about it.
Oct 22 00:52:49 <clsk> Max?
Oct 22 00:53:00 <J_K9> I've only done a spec for the Directory module so far
Oct 22 00:53:05 <J_K9> https://blueprints.launchpad.net/mira/+spec/directory-layer
Oct 22 00:54:25 <ifdef5> ok - that's agood start
Oct 22 00:55:11 <J_K9> I wrote something more in-depth on roles a while back on the forums though: http://miragroupware.org/forums/index.php?topic=24.0
Oct 22 00:55:26 <J_K9> Perhaps that could be adapted and added to the wiki to make the roles system clearer?
Oct 22 00:58:00 <clsk> yea, you should probably put that on the wiki
Oct 22 00:58:14 <ifdef5> i have to roll in a few minutes, but I'll add #mira to my watchlist, and will hang around most of the time i'm online
Oct 22 00:58:29 <J_K9> great, thanks Fred
Oct 22 00:58:39 <clsk> ok Fred.
Oct 22 00:58:50 <J_K9> clsk - should I put it within the Directory layer spec or just refer to it from the spec?
Oct 22 00:58:51 <clsk> so what part do you plan on working on?
Oct 22 00:59:06 <clsk> hm just refer to it from the spec.
Oct 22 00:59:41 <ifdef5> :) i'm still not sure what's needed. I guess I'll poke around in the file sharing stuff, see what looks open and ask
Oct 22 01:00:06 <clsk> ok that works.
Oct 22 01:00:19 <clsk> what about you Naveen?
Oct 22 01:00:23 <ifdef5> see you next time guys. thanks!
Oct 22 01:00:32 <J_K9> thank you, Fred! until next time!
Oct 22 01:00:39 <clsk> Do you think you can get the client-side network working?
Oct 22 01:00:43 <Naveen> as Max suggested, I will take up the gui and try to communicate with networking and storage stuff from alan
Oct 22 01:00:46 <clsk> alright fred. Take care. thanks.
Oct 22 01:00:53 <Naveen> is it ok, clsk
Oct 22 01:01:07 <clsk> cool.
Oct 22 01:02:26 * ifdef5 has quit ()
Oct 22 01:02:43 <Naveen> Next, I will try building a gui with file sharing
Oct 22 01:03:01 <J_K9> that sounds great Naveen
Oct 22 01:03:09 <Naveen> ofcourse while security is being discussed
Oct 22 01:03:43 <clsk> hey what part of miami are you at?
Oct 22 01:03:54 <Naveen> Doral
Oct 22 01:04:03 <Naveen> you here?
Oct 22 01:04:34 <clsk> nah I'm from hollywood, fl. about hm 30 mins away from you
Oct 22 01:04:39 <clsk> but I'm in iraq right now
Oct 22 01:04:48 <Naveen> :)
Oct 22 01:05:01 <Naveen> I was in Miramar for 2yrs
Oct 22 01:05:07 <clsk> oh really
Oct 22 01:05:26 <Naveen> till when is your present assignment
Oct 22 01:05:31 <clsk> I'm actually from pembroke pines, my school was in hollywood. But no one ever knows where pembroke pines is
Oct 22 01:05:54 <Naveen> almost no one, now
Oct 22 01:05:56 <clsk> I just got here. Until october of next year.
Oct 22 01:06:00 <clsk> yea heh
Oct 22 01:06:43 <J_K9> until october of next year? wow, that's a long time. isn't it usually around 6 months?
Oct 22 01:06:53 <clsk> wallmart on pembroke road and university. That's around where my house is.
Oct 22 01:06:59 <clsk> nah 6 months for air force
Oct 22 01:07:05 <J_K9> ah
Oct 22 01:07:07 <clsk> Army tours just got increased to 15 months
Oct 22 01:07:15 <clsk> Last time I was here was for 12 months
Oct 22 01:07:15 <J_K9> wow
Oct 22 01:07:28 <clsk> hopefully this will be my last time
Oct 22 01:08:03 <Naveen> hopefully by then Mira is working and can have a beer when you're back
Oct 22 01:09:06 <J_K9> make that 3 beers - I may be visiting American universities at the time ;)
Oct 22 01:09:26 <Naveen> great
Oct 22 01:09:59 <beyonddc> MIT welcomes you.
Oct 22 01:10:12 <J_K9> David, are you at MIT?
Oct 22 01:10:16 <beyonddc>
Oct 22 01:10:23 <beyonddc> Nope!
Oct 22 01:10:31 <J_K9> lol alright
Oct 22 01:10:37 <beyonddc> I graduated from WIT. Haha..
Oct 22 01:10:43 <J_K9> :P
Oct 22 01:10:50 <beyonddc> Just reserve the W and you get M.
Oct 22 01:11:01 <beyonddc> reverse*
Oct 22 01:11:06 <J_K9> hehe!
Oct 22 01:11:14 <clsk> heh yea
Oct 22 01:11:14 <clsk> cool
Oct 22 01:11:55 <clsk> hm is that in massachusetts too?
Oct 22 01:12:01 <beyonddc> Yea..
Oct 22 01:12:22 <beyonddc> I'm just 40 minutes South of Boston.
Oct 22 01:12:42 <clsk> oh
Oct 22 01:12:43 <clsk> cool
Oct 22 01:13:00 <clsk> You're still attending school or are you done already?
Oct 22 01:13:18 <beyonddc> I'm done.
Oct 22 01:13:24 <beyonddc> Graduated from college 4 years ago.
Oct 22 01:13:36 <clsk> oh ok
Oct 22 01:14:06 <clsk> well I should go to sleep. I went to sleep late last night trying to get something to work on mira.
Oct 22 01:14:29 <J_K9> it must be quite late there?
Oct 22 01:14:47 <clsk> yea. 2:18am.
Oct 22 01:14:57 <clsk> I work a late shift though
Oct 22 01:15:03 <J_K9> ah, ok
Oct 22 01:15:09 <clsk> 4pm - 12am. So I normally go to sleep at 4am
Oct 22 01:15:24 <beyonddc> I need to reinstall boost.
Oct 22 01:15:32 <J_K9> well, thanks to everyone for attending this meeting - we'll have another one in a few days, I think, but it'll be more specialised
Oct 22 01:15:35 <beyonddc> Alan you're using 1.35 already?
Oct 22 01:15:41 <beyonddc> Boost 1.35
Oct 22 01:15:46 <J_K9> is it out?
Oct 22 01:15:47 <clsk> hm no. It already came out?
Oct 22 01:16:00 <clsk> I'm using cvs though, so I should be fine for the most part.
Oct 22 01:16:46 <clsk> 1.35 should have asio on it already
Oct 22 01:16:47 <clsk> right?
Oct 22 01:16:48 <beyonddc> I'm looking at the Makefile, and it said you've boost installed in /usr/local/include/boost-1_35
Oct 22 01:17:26 <clsk> Where did you get it from?
Oct 22 01:17:55 <beyonddc> mira-server/Makefile
Oct 22 01:18:07 <clsk> oh that's right they already increased the version number in cvs a couple of days ago. They're about to release 1.35 I suppose.
Oct 22 01:18:11 <clsk> oh
Oct 22 01:18:12 <clsk> ok
Oct 22 01:18:15 <J_K9> oh, ok
Oct 22 01:18:22 <J_K9> got it now :)
Oct 22 01:18:25 <clsk> yea, it's the cvs verison. They already increased the version number
Oct 22 01:18:48 <beyonddc> I am installing the stable version 1.34.1 and getting asio seperately.
Oct 22 01:18:54 <beyonddc> I'll wait for the official release
Oct 22 01:18:59 <clsk> btw, max, did you finish installing boost?
Oct 22 01:19:01 <beyonddc> I think I shouldn't have problem compiling.
Oct 22 01:19:12 <J_K9> I haven't compiled it yet, but it has finished checking out
Oct 22 01:19:16 <clsk> yea, just change Makefile.am
Oct 22 01:19:30 <clsk> and you'll be fine.
Oct 22 01:19:48 <beyonddc> I need to get going now. ttyl.
Oct 22 01:20:00 <J_K9> sure. thanks again guys! ttys
Oct 22 01:20:10 <Naveen> thanks guys
Oct 22 01:20:15 <clsk> alright I have to go too
Oct 22 01:20:19 <clsk> thanks :)
Oct 22 01:20:40 <clsk> Naveen if you have any questions about anything don't hesitate to email me
Oct 22 01:20:41 <Naveen> g'nite everyone
Oct 22 01:20:54 <clsk> gnite
Oct 22 01:20:56 <J_K9> 'night!
Discussion