Developer Meeting 02/06/2007 15:00 UTC
Attendees: beyonddc, clsk, Cupu, J_K9
Note: All timestamps in UTC+1 (British Summer Time).
Jun 02 16:12:26 <J_K9> right, I think the ten minutes are up… shall we begin? unless anyone wants to wait slightly longer for Ananth and possibly Daryl
Jun 02 16:13:07 <beyonddc> We can begin, but I don't know how useful would that be without Ananth. 
Jun 02 16:13:20 <Cupu> I agree a little
Jun 02 16:13:26 <Cupu> since the filesharing part was his concept
Jun 02 16:13:31 <J_K9> true
Jun 02 16:13:52 <Cupu> of course we could tackle other outstanding issues if they exist
Jun 02 16:13:58 <J_K9> indeed
Jun 02 16:14:06 <beyonddc> Yes, we can do that.
Jun 02 16:14:19 <J_K9> has everyone managed to have a look over the definition study? http://miragroupware.org/wiki/doku.php/development/def_study
Jun 02 16:14:35 <beyonddc> oh… give me 2 mins on that. I looked at the old version couple days ago
Jun 02 16:14:53 <J_K9> no problem
Jun 02 16:15:53 <clsk> brb
Jun 02 16:15:55 <clsk> fire alarm
Jun 02 16:15:59 <J_K9> ok
Jun 02 16:16:20 <J_K9> hehe.. what are the chances? :p
Jun 02 16:16:25 <Cupu> :))
Jun 02 16:16:28 <beyonddc> shall provide a context-aware help service - what does that mean?
Jun 02 16:16:44 <beyonddc> Just a help?
Jun 02 16:16:49 <J_K9> that means that, for example, pressing F1 while in the Files Utility will bring up the relevant help section
Jun 02 16:16:59 <Cupu> Just 10 minutes ago I read that xchm has context aware help .. but that refers only to the f1 and search capabilities
Jun 02 16:17:04 <J_K9> whatever help services we provide would be aware of where the user is
Jun 02 16:17:13 <Cupu> that was also something that I wasn't sure of .. but yeah .. it makes sense
Jun 02 16:17:32 <J_K9> yes, it's quite a useful feature
Jun 02 16:17:49 <J_K9> rather than having to search for it in the help files :)
Jun 02 16:17:59 <beyonddc> shall allow Users to have discussions in real-time with other Users of the same Workplace. I think that's an utility requirement. May I suggest to rephrase this to something like “shall provide an utility to allow users to have discussions in real-time with other Users of the same Workplace”
Jun 02 16:18:17 <J_K9> no, it's not a Utility
Jun 02 16:18:41 <J_K9> it will be an integrated part of the application itself which the Project Manager may enable or disable in the Workplace
Jun 02 16:18:45 <Cupu> It can be a utility . but since we MUST provide it .. it should be a core feature
Jun 02 16:18:55 <Cupu> I mean .. it's an Utility to the users .. but a core feature to the devs
Jun 02 16:19:01 <J_K9> the good thing about it is that it lets the User enter different Utilities in a Workplace while remaining in real-time contact with others
Jun 02 16:19:22 <J_K9> which is why I think it would be better as a core part of the app rather than as a Utility
Jun 02 16:19:28 <beyonddc> yes, it is a core functionality, but we should clearly distinguish between utility and the core.
Jun 02 16:19:41 <J_K9> indeed
Jun 02 16:19:56 <beyonddc> my view is everything that interacts with an user is an utility.
Jun 02 16:20:12 <J_K9> and it shall eventually become part of the core, just as the contacts list is part of the core :)
Jun 02 16:20:46 <J_K9> have you all seen the latest mock-ups? they're not consistent in terms of text content, but they give a good idea of the underlying functionality required to make it work: http://miragroupware.org/screenshots.php
Jun 02 16:21:51 <beyonddc> I think that's where the confusion begin. Like remember couple of e-mails ago I mentioned about that what we're developing is like an infrastructure. The infrastructure is the platform where all utility will plug into.
Jun 02 16:22:13 <beyonddc> contact list, disucssion message to me is all utility that plug into the platform
Jun 02 16:22:34 <J_K9> hmm, no, they're different parts of the platform
Jun 02 16:22:56 <J_K9> if you look at the mock-ups, the Utilities are strictly the list of tools that appear under an expanded Workplace in the Navigator
Jun 02 16:23:09 <beyonddc> k, let me take a quick look
Jun 02 16:23:21 <J_K9> the Navigator, Contacts List, Chat etc are parts of the platform but are not Utilities
Jun 02 16:23:33 <Cupu> How do we enforce utility installations on the client?
Jun 02 16:23:48 <Cupu> I mean clearly some (a lot) of client utilities will require server utilities to be installed
Jun 02 16:23:52 <Cupu> I mean plug-ins …
Jun 02 16:23:58 <J_K9> yes
Jun 02 16:24:00 <clsk> hey I'll think I'll be a while
Jun 02 16:24:09 <J_K9> ok
Jun 02 16:24:10 <clsk> some constructors hit a gas pipe
Jun 02 16:24:11 <clsk> so
Jun 02 16:24:12 <Cupu> will the admin install whatever they want .. and the suers be presented with a list of what's available on the server?
Jun 02 16:24:18 <clsk> I don't know how long it will be
Jun 02 16:24:22 <clsk> have tyo go
Jun 02 16:24:23 <clsk> bye
Jun 02 16:24:27 <J_K9> no probs clsk - cya
Jun 02 16:24:29 <beyonddc> good luck stefen
Jun 02 16:24:34 <beyonddc> i mean
Jun 02 16:24:37 <beyonddc> alan
Jun 02 16:24:38 <beyonddc> 
Jun 02 16:24:39 <beyonddc> ;x
Jun 02 16:25:08 <Cupu> :)
Jun 02 16:25:10 <Cupu> brb phone
Jun 02 16:25:13 <beyonddc> oih…regarding with enforcing client with plugin
Jun 02 16:25:14 <J_K9> Cupu - that would be a good way of going about it
Jun 02 16:25:31 <beyonddc> i think stefen is right on that. Server will be configured and know which plugin is needed
Jun 02 16:25:52 <beyonddc> when client connects, the server will check if clients got all plugin, if not, it will provide an instruction on how to install it or something like that
Jun 02 16:26:00 <J_K9> when the Utility is installed on the server, the Client installation files could also be on there and then passed to the Client when a Client connects and does not have it?
Jun 02 16:27:01 <beyonddc> naw, maybe just provide them with a link online to download it. The installer will then automatically configure it for the user.
Jun 02 16:27:19 <J_K9> although.. if we want it to be self-updatable, Mira Server would have to check the Utilities website periodically for updates to the Utilities on both the Server and Client side
Jun 02 16:27:20 <beyonddc> but that can be work out later. It's not urgent.
Jun 02 16:27:29 <J_K9> yes, I agree
Jun 02 16:27:36 <beyonddc> regarding with the GUI.
Jun 02 16:28:01 <beyonddc> it still looks like a plugin to me
Jun 02 16:28:05 <beyonddc> 
Jun 02 16:28:10 <J_K9> what looks like a plugin?
Jun 02 16:28:15 <beyonddc> the contact list
Jun 02 16:28:33 <beyonddc> Let me explain a little further
Jun 02 16:28:50 <J_K9> it isn't a plugin because it's separated from the main pane/window of the Client application. it is a module, but it's not a Utility and it's not built upon the Utility API :)
Jun 02 16:29:06 <Cupu> While I agree with David that we're aiming for “extension Utopia” … we will have to have the server REQUIRE a few plug-ins/utilities on the client …
Jun 02 16:29:14 <Cupu> otherwise mira will be an empty window :)
Jun 02 16:29:17 <Cupu> (the client that is)
Jun 02 16:29:18 <beyonddc> yes Max, but there's built-in plugin and extra plugin
Jun 02 16:29:27 <J_K9> i know
Jun 02 16:29:32 <beyonddc> either way, the contact list or the exta plugin will sit ontop of the same API
Jun 02 16:29:39 <beyonddc> so that made them plug-in
Jun 02 16:29:39 <J_K9> but the Contacts List will not be Workplace-specific
Jun 02 16:30:02 <beyonddc> Sure, no problem, but they're still plugin stis on top of the same API.
Jun 02 16:30:12 <beyonddc> okay…
Jun 02 16:30:18 <beyonddc> let me rephrase
Jun 02 16:30:24 <J_K9> in that case, the Contact List wouldn't be a plugin but the Chat would according to this, because of it being built on top of the API?
Jun 02 16:30:28 <Cupu> David's got the key, the fact that it sits on the same API
Jun 02 16:30:36 <beyonddc> yes Stefen
Jun 02 16:30:39 <J_K9> aye
Jun 02 16:30:48 <J_K9> I now agree with that for the Chat plugin
Jun 02 16:31:34 <beyonddc> So that's why in all those e-mails, I kept saying everything is a plugin.
Jun 02 16:31:36 <J_K9> but as for the Contact List… the problem with that is it needs to be separated from Workplace (i.e. Workplace-unaware), a functionality we would have to implement into the Utilities API
Jun 02 16:31:49 <J_K9> that might be a security risk because we don't want other Utilities being cross-Workplace too
Jun 02 16:32:16 <Cupu> I think we're all saying the same thing but in different words
Jun 02 16:32:28 <beyonddc> i think so too
Jun 02 16:32:33 <Cupu> deep down there is the api
Jun 02 16:32:44 <Cupu> next level there the utilities API .. a specialization ..
Jun 02 16:32:44 <beyonddc> yes
Jun 02 16:32:48 <beyonddc> yes
Jun 02 16:32:59 <Cupu> it's brother .. the whateverAPI .. another specialization
Jun 02 16:33:31 <beyonddc> At this point, what we're doing is the deep down API that you're talking about.
Jun 02 16:34:19 <Cupu> Perfect .. just like building a house
Jun 02 16:34:20 <beyonddc> Max, regarding with security. That's something we need to think about.
Jun 02 16:34:21 <J_K9> that deep down system is the networking implementation, parser, storage system etc, correct?
Jun 02 16:34:27 <beyonddc> Yes Max
Jun 02 16:34:28 <J_K9> beyonddc - definitely
Jun 02 16:34:33 <beyonddc> Yay, we're on track!
Jun 02 16:34:38 <J_K9> hehe! for now 
Jun 02 16:34:47 <J_K9> so let's discuss the lowest layer
Jun 02 16:35:23 <beyonddc> Max, so for requirement, it would be nice to seperate those requirements into layer
Jun 02 16:35:30 <beyonddc> such as requirement for networking implementation
Jun 02 16:35:36 <beyonddc> requirement for parser
Jun 02 16:35:41 <beyonddc> requirement for version control and etc
Jun 02 16:35:46 <J_K9> yes, that's a good point
Jun 02 16:36:03 <beyonddc> that's going to give us the developer a very good information.
Jun 02 16:36:04 <J_K9> would that be something to do in the SRS or DS?
Jun 02 16:36:24 <beyonddc> I don't know Max
Jun 02 16:36:30 <beyonddc> I only deal with SRS at work
Jun 02 16:36:32 <J_K9> as the DS is, in effect, an overview, perhaps the SRS would be better for that.
Jun 02 16:36:32 <beyonddc> I don't know what's DS is
Jun 02 16:36:38 <J_K9> definition study
Jun 02 16:36:39 <J_K9> :)
Jun 02 16:36:41 <beyonddc> I know
Jun 02 16:36:44 <beyonddc> we don't use that
Jun 02 16:36:46 <J_K9> oh, right
Jun 02 16:36:55 <beyonddc> or atleast I don't read it
Jun 02 16:36:56 <beyonddc>
Jun 02 16:36:59 <J_K9> lol!
Jun 02 16:37:04 <beyonddc> there's so much documentation to read at work
Jun 02 16:37:13 <beyonddc> I think it will take me years to finish reading it.
Jun 02 16:37:16 <J_K9> hehe
Jun 02 16:37:58 <beyonddc> by the way, that's why I used the word “mira infrastructure” or “mira platform” to describe the low level functionality.
Jun 02 16:38:05 <J_K9> yes
Jun 02 16:38:11 <J_K9> ok
Jun 02 16:38:34 <J_K9> so which subsystem shall we discuss?
Jun 02 16:38:41 <beyonddc> one more thing
Jun 02 16:38:44 <J_K9> ok
Jun 02 16:38:56 <beyonddc> The naviagor on your mockup can be a core in the GUI.
Jun 02 16:39:15 <beyonddc> that's like a list of plug-in installed
Jun 02 16:39:27 <Cupu> I'm sorry .. excuse me for a couple of minutes .. but do kep talking .. I'm logging everything and will read
Jun 02 16:39:34 <J_K9> no probs Cupu
Jun 02 16:39:56 <beyonddc> I think the GUI part will have its own core functionality
Jun 02 16:40:04 <beyonddc> but talk can save for later
Jun 02 16:40:11 <beyonddc> i mean that talk can save for later
Jun 02 16:40:32 <J_K9> yes. i agree about the navigator as a core part of the GUI btw - it requires very little functionality to work
Jun 02 16:40:42 <beyonddc> we can talk about the low level stuff now
Jun 02 16:40:46 <J_K9> ok
Jun 02 16:40:56 <J_K9> we cannot talk about the storage system without Ananth
Jun 02 16:40:56 <beyonddc> version control?
Jun 02 16:41:04 <beyonddc> true
Jun 02 16:41:22 <J_K9> well, we don't need to rule it out altogether - go ahead :)
Jun 02 16:41:41 <Cupu> I'm not back yet .. but just wanted to mention a concern of mine .. it's the separate client side daemon …
Jun 02 16:41:43 <beyonddc> well, i want to talk a little about the thoughts i've in the version control area.
Jun 02 16:42:04 <beyonddc> Why worry?
Jun 02 16:42:04 <J_K9> Cupu - point noted. we'll talk about that when you get back :)
Jun 02 16:42:08 <beyonddc> okay
Jun 02 16:42:14 <Cupu> Perhaps I should make an email about that … while I'm ok with it's functionality .. I don't think having the separate deamon is .. well .. client friendly .. but I'll be back :)
Jun 02 16:42:23 <J_K9> ok
Jun 02 16:42:33 <beyonddc> version control….
Jun 02 16:42:36 <J_K9> indeed :)
Jun 02 16:42:54 <beyonddc> I mentioned about every functionality we're providing will be described in an API
Jun 02 16:43:02 <beyonddc> such as “creating a file*
Jun 02 16:43:12 <J_K9> yes
Jun 02 16:43:21 <beyonddc> “duration of each auto sync*
Jun 02 16:43:32 <beyonddc> the duration could be per plug-in or per file
Jun 02 16:43:40 <beyonddc> but I think Ananth has some objection to that.
Jun 02 16:43:52 <J_K9> he's against auto-syncing
Jun 02 16:44:04 <J_K9> because he believes that should be left up to the user, particularly in the Files Utility
Jun 02 16:44:28 <J_K9> with that last part I can agree. However, I do think we should display pop-ups so as to encourage the user to upload their changes
Jun 02 16:44:30 <beyonddc> Yes, but it doesn't mean we cannot provide an API to do so
Jun 02 16:45:00 <J_K9> for auto-syncing?
Jun 02 16:45:01 <beyonddc> Max, you're off track again. No GUI talk, that is utility reponsibility
Jun 02 16:45:17 <beyonddc> Yes, Max, API for auto-syncing
Jun 02 16:45:20 <J_K9> ok
Jun 02 16:45:29 <beyonddc> File utility might not need auto-syncing but some other plugin might need it
Jun 02 16:45:59 <J_K9> well, the three storage backends we were thinking of were SVN (i.e. version control), standard (no version control) and real-time
Jun 02 16:46:14 <J_K9> an API would be provided for each and a Utility developer could choose one of the three
Jun 02 16:46:43 <J_K9> in the API of each we could allow for the Utility developer to choose when the data is synchronised?
Jun 02 16:46:54 <beyonddc> I think regarding with your pop-up talk. We can translate it into something like “file sharing component shall notify an utility when a file is changed/moidified/delete”
Jun 02 16:46:58 <beyonddc> something like that
Jun 02 16:47:06 <J_K9> yes
Jun 02 16:47:47 <beyonddc> the notification will be up to ananth to figure out. We just provide them requirement. if ananth doesn't feel comfortable with it, he can bring it up and we talk more about it.
Jun 02 16:47:52 <J_K9> but that should be an interpretation of a local change by the Files Utility and thus a requirement of that Utility, not of the platform as a whole, so we can leave that till later
Jun 02 16:48:28 <beyonddc> k
Jun 02 16:48:57 <beyonddc> What're the 3 storage backends again?
Jun 02 16:49:02 <beyonddc> I only read 2 up there.
Jun 02 16:49:20 <J_K9> SVN, real-time and non-version controlled delayed
Jun 02 16:49:49 <J_K9> that last one is where there is no version control support and the data is synchronised as soon as there is a change, e.g. Calendar Utility or Notes Utility
Jun 02 16:50:18 <beyonddc> yes Max, I don't think we need to worry about third.
Jun 02 16:50:25 <J_K9> really?
Jun 02 16:50:44 <beyonddc> The third option can be anything. Storing a note, storing a calender can be file based
Jun 02 16:50:47 <beyonddc> or store into a database
Jun 02 16:50:52 <J_K9> indeed
Jun 02 16:51:14 <J_K9> and if it were stored in a database, it should neither be handled by SVN or the real-time backends
Jun 02 16:51:18 <J_K9> at least, not IMHO
Jun 02 16:51:20 <beyonddc> What's Ananth is concentrate on is just version control (with or without auto-sync).
Jun 02 16:51:33 <beyonddc> the database will be a different layer
Jun 02 16:51:47 <beyonddc> it will not be part of what's ananth is working on
Jun 02 16:51:49 <J_K9> but an API for it must be provided as a storage system in the Utilities API
Jun 02 16:52:12 <J_K9> true… he will be working on integrated the version control system as a storage backend
Jun 02 16:52:18 <beyonddc> yes..
Jun 02 16:52:19 <J_K9> *integrating
Jun 02 16:52:23 <beyonddc> database is totally different thing
Jun 02 16:52:32 <beyonddc> maybe it deserves its own set of requirement
Jun 02 16:52:36 <J_K9> true, but we must not forget it as a data transmission system
Jun 02 16:52:38 <J_K9> it does
Jun 02 16:52:48 <J_K9> as does the real-time system, another completely different layer
Jun 02 16:52:48 <beyonddc> yes…
Jun 02 16:53:10 <beyonddc> what kind of real-time system are you talking about? what functionality in particular
Jun 02 16:53:21 <J_K9> I'm thinking of Utilities like the Whiteboard Utility
Jun 02 16:53:37 <beyonddc> utility like whiteboard will be using the networking layer.
Jun 02 16:53:45 <beyonddc> that's what alan and I will be work on
Jun 02 16:53:53 <beyonddc> we provide them with an API to do that kind of data transmission
Jun 02 16:54:01 <J_K9> ah, yes, you are right.
Jun 02 16:54:05 <beyonddc> Alan, I and Stefen to be exact
Jun 02 16:54:37 <beyonddc> cool, we're on track again.
Jun 02 16:54:46 <beyonddc> Much better to talk in a chat form then on email
Jun 02 16:54:59 <J_K9> yes, talking in real-time does help!
Jun 02 16:55:12 <beyonddc> Did I confused you in e-mail?
Jun 02 16:55:32 <J_K9> no, but I think I have just filled the gaps in my mind incorrectly
Jun 02 16:55:34 <J_K9> :)
Jun 02 16:55:42 <beyonddc> okay
Jun 02 16:55:54 <beyonddc> Yes, it's not just the file utility that needs the version control, it can be anything
Jun 02 16:56:04 <J_K9> indeed
Jun 02 16:56:22 <J_K9> but we have to think about how the data of other Utilities requiring the version control system would be stored
Jun 02 16:56:40 <beyonddc> Basically what we're providing as a platform/infrastructure is just a set of well defined functionality and we'll let the utility develooper to pick and choice whatever they want to use.
Jun 02 16:56:41 <J_K9> although, for that, we'd need to know what other kinds of Utilities might use the version control storage system
Jun 02 16:56:47 <J_K9> exactly
Jun 02 16:57:12 <beyonddc> yes Max, we need to *try* think ahead, but I will not overkill on this part.
Jun 02 16:57:26 <beyonddc> Right now we can just concentrate on making an infrastrature for *file utility*
Jun 02 16:57:34 <J_K9> yes
Jun 02 16:57:42 <beyonddc> after we get that working, we can add more cool stuffs in the infrastructure
Jun 02 16:57:50 <J_K9> then, once we realise that there are other requirements, we may implement those
Jun 02 16:57:58 <beyonddc> yes..
Jun 02 16:58:00 <J_K9> ok
Jun 02 16:58:21 <J_K9> how about defining the roadmap for the 0.1 release? do you want to do that now?
Jun 02 16:58:48 <beyonddc> nope, i think that should invovle everyone.
Jun 02 16:59:08 <J_K9> true, but we can do it for the networking section now
Jun 02 16:59:14 <J_K9> we could then edit it later after consulting the others
Jun 02 16:59:29 <J_K9> peer review is, of course, required for all of these documents
Jun 02 17:00:03 <beyonddc> sorry, i haven't really thought about the networking layer yet. I was having fun with emails..coding standards and svn skeleton this week
Jun 02 17:00:32 <beyonddc> I know Alan started coding.
Jun 02 17:00:48 <beyonddc> We talked during the week and we exchanged some general programming issue.
Jun 02 17:00:48 <J_K9> no problem - we are still very much defining the requirements, so we've got a while left before we begin putting our code together
Jun 02 17:00:52 <J_K9> ah
Jun 02 17:01:12 <beyonddc> I think he's just getting generic code done.
Jun 02 17:01:30 <beyonddc> so it should be fine if his code is different from the requirement. Those can be modify.
Jun 02 17:01:43 <J_K9> yes, definitely
Jun 02 17:02:15 <beyonddc> so how I do at work is… we've a SRS, and then SRS is organized by feature, each feature has a set of reuqirements
Jun 02 17:02:27 <beyonddc> each requirement has a target release column
Jun 02 17:02:38 <beyonddc> the target release column in SRS is sort of like the road map
Jun 02 17:02:49 <J_K9> i see
Jun 02 17:02:52 <beyonddc> yea
Jun 02 17:03:08 <J_K9> I do have an SRS template which I will be uploading to the wiki and which we will all be editing and contributing to
Jun 02 17:03:12 <beyonddc> so when we've the requirments, we can then generate the road map more precisly.
Jun 02 17:03:16 <J_K9> indeed
Jun 02 17:03:21 <beyonddc> sure
Jun 02 17:03:28 <J_K9> we can select the most necessary and core requirements for the first release
Jun 02 17:03:38 <J_K9> and then implement the less important requirements per release
Jun 02 17:03:42 <beyonddc> yes
Jun 02 17:03:46 <beyonddc> i agree w/ you
Jun 02 17:03:52 <J_K9> ok :)
Jun 02 17:04:23 <beyonddc> At work, I'm also working on an infrastructure.
Jun 02 17:04:23 <Cupu> Hey, I've managed to read everything .. I'm still here .. but there's this neighbour who isn;t sure what he wants …
Jun 02 17:04:28 <Cupu> I'll pop in as much as I can
Jun 02 17:04:32 <beyonddc> sure Stefen
Jun 02 17:04:39 <J_K9> cheers Stefan!
Jun 02 17:04:54 <beyonddc> But the infrastructure is a lot more different
Jun 02 17:05:02 <J_K9> in what sense?
Jun 02 17:05:17 <beyonddc> We've a resource manager as an executable that starts and stop programs and take care of memory allocation and stuff
Jun 02 17:05:25 <beyonddc> we've directory services
Jun 02 17:05:29 <beyonddc> we've task manager
Jun 02 17:05:42 <beyonddc> we've database services
Jun 02 17:05:53 <beyonddc> we've a distributed service
Jun 02 17:06:09 <beyonddc> directory service uses LDAP and database uses oracle
Jun 02 17:06:36 <beyonddc> it's different because the infrastructure i am working on is some what like an OS, we bring up and bring down application
Jun 02 17:06:50 <J_K9> ah
Jun 02 17:06:54 <beyonddc> and the mira infrastructure is much smaller
Jun 02 17:07:01 <J_K9> yes, it appears so!
Jun 02 17:07:04 <beyonddc> because it's within an app
Jun 02 17:07:08 <beyonddc> eh
Jun 02 17:07:34 <J_K9> although Mira should be able to interface with such services (e.g. LDAP) in the future, but that is many versions away :)
Jun 02 17:08:01 <beyonddc> yea..i really don't know how necessary that is, but we can talk later on this.
Jun 02 17:08:09 <beyonddc> I always think the less dependency the better
Jun 02 17:08:34 <J_K9> it's not necessary and it shouldn't be a dependency - it should just be an option for the server admin to add another way of authenticating users, for example
Jun 02 17:08:40 <beyonddc> but i guess if you really want to bring mira up to the enterprise level, then that probably is a must.
Jun 02 17:08:47 <J_K9> to allow Mira to become a more integral part of their environment
Jun 02 17:09:22 <beyonddc> who do you think would be the target audience for Mira?
Jun 02 17:09:46 <Cupu> There should be a lot and very diverse audience
Jun 02 17:09:51 <J_K9> mainly SMBs and small enterprises
Jun 02 17:10:02 <J_K9> but, as Stefan said, anyone can use this to increase their productivity
Jun 02 17:10:03 <beyonddc> I was thinking college students.
Jun 02 17:10:06 <J_K9> yes, as well
Jun 02 17:10:09 <Cupu> for example companies like Oracle in romania have their own separate IM platform .. and document exchange and the like for their employes
Jun 02 17:10:17 <J_K9> I was just telling my brother about it the other day
Jun 02 17:10:21 <Cupu> that would be a prefect place for MIRA
Jun 02 17:10:30 <J_K9> yes
Jun 02 17:10:39 <Cupu> same for Microsoft here .. but really .. any company that has a lot of employes on computers is a candidate
Jun 02 17:10:52 <J_K9> indeed
Jun 02 17:11:01 <beyonddc> yes, if we're aiming for that group of audience (businesses), we better have a good security framework in place.
Jun 02 17:11:22 <J_K9> Mira will be an extensible all-in-one system, which is why it will be so attractive to these businesses
Jun 02 17:11:29 <J_K9> David, that is definitely true
Jun 02 17:11:56 <J_K9> Mira needs to be very stable too to tackle the availability aspect of security
Jun 02 17:12:03 <Cupu> If we won't have good security we better not realease anythign :D
Jun 02 17:12:13 <J_K9> hehe!
Jun 02 17:12:26 <J_K9> yes
Jun 02 17:12:59 <J_K9> for confidentiality, using SSL to secure data when it's being transmitted over the network should be possible with Boost/asio, correct?
Jun 02 17:13:14 <beyonddc> There's so much tradeoff, but that's later talk again. Security and Performance is hard to balance.
Jun 02 17:13:21 <beyonddc> and performance and relability is also hard to balance
Jun 02 17:13:38 <J_K9> and as for integrity, as we're using SVN for version control that should be fine (and for the other backends we can use checksums)
Jun 02 17:13:45 <J_K9> that's not necessarily true
Jun 02 17:13:48 <beyonddc> asio has a wrapper ontop of SSL
Jun 02 17:13:56 <Cupu> asio has support for SSL
Jun 02 17:14:04 <Cupu> oh …. what David said :)
Jun 02 17:14:05 <J_K9> although I do agree that optimisation must be kept at a minimum in order to improve its stability across platforms
Jun 02 17:14:18 <J_K9> ah, ok - that's good :)
Jun 02 17:14:35 <Cupu> listen … we can either build smart C++ or very “optimised” java for example
Jun 02 17:14:55 <Cupu> I think c++ is a good choice .. and as long as we don't do bad mistakes .. we should be very ok performance wise
Jun 02 17:15:02 <J_K9> yes, I agree
Jun 02 17:15:20 <Cupu> plus .. you know .. premature optimization is the root of all evil :D .. so until we have something working .. I will delete the optimization word from my vocabulary
Jun 02 17:15:34 <J_K9> and so long as we keep the cross-platform techniques constantly in mind the stability of the systems should not be affected
Jun 02 17:15:49 <J_K9> Cupu - haha! yes, as will I
Jun 02 17:15:58 <J_K9> I completely agree
Jun 02 17:16:09 <beyonddc> I wouldn't put performance as the key of mira. Stability is the key of mira
Jun 02 17:16:18 <Cupu> Right you are
Jun 02 17:16:36 <J_K9> indeed
Jun 02 17:16:52 <beyonddc> by the way, Java is not really that slow. Especially with the new version of Java.
Jun 02 17:17:01 <Cupu> Oh .. I just wanted to say something
Jun 02 17:17:14 <Cupu> After I've written java .. I was afraid not to start something
Jun 02 17:17:31 <beyonddc> what do you mean? afraid not to start something?
Jun 02 17:17:33 <Cupu> let's forget I said that .. I wanted to say that if we manipulate c++ the right way .. performance should not be an issue
Jun 02 17:17:44 <Cupu> A holy war :)
Jun 02 17:17:44 <beyonddc> lol
Jun 02 17:17:47 <J_K9> hehe
Jun 02 17:18:22 <beyonddc> Just to let you know…
Jun 02 17:18:39 <beyonddc> A lot of new combat system is programmed in Java.
Jun 02 17:18:45 <J_K9> C++ is a good choice. it'll take longer to code that platform than in Java, but it will allow us more control and should be slightly faster in any case
Jun 02 17:18:46 <Cupu> :)
Jun 02 17:18:48 <J_K9> really?
Jun 02 17:18:57 <beyonddc> Yes..
Jun 02 17:19:12 <J_K9> because most of the large Java apps I have used are noticeably slower than C++ apps of the same size, for example
Jun 02 17:19:16 <Cupu> Well .. my “managed” language will probably be java as opposed to c# or c++ cli .. and I have done some Java a couple of years back
Jun 02 17:19:25 <Cupu> I have nothing against it .. I just don't feel like usin it right now
Jun 02 17:19:33 <Cupu> *using
Jun 02 17:19:43 <Cupu> of course if Java would buy me a better keyboard ….
Jun 02 17:19:48 <J_K9> lol
Jun 02 17:19:54 <J_K9> back to that one are we? :p
Jun 02 17:20:03 <Cupu> We do what we can :)
Jun 02 17:20:20 <J_K9> hehe, indeed ;)
Jun 02 17:20:51 <beyonddc> http://www-03.ibm.com/press/us/en/pressrelease/21033.wss
Jun 02 17:21:08 <beyonddc> JAVA and Red Hat is used in the new US Destroyer.
Jun 02 17:21:14 <beyonddc> It will be a linux based ship
Jun 02 17:21:17 <Cupu> good one for navy destroyers
Jun 02 17:21:32 <Cupu> Well .. it is .. really .. I have nothing against java .. please believe me :)
Jun 02 17:21:41 <J_K9> aye
Jun 02 17:21:50 <J_K9> interesting :)
Jun 02 17:21:50 <beyonddc> well… the ship will be running with a mixture of Java and realtime java
Jun 02 17:21:59 <Cupu> I've studied java before c++ actually .. I just like c++ a little more …
Jun 02 17:22:28 <beyonddc> My main language is c++ and java. I switch back and forth constantly during work.
Jun 02 17:22:47 <beyonddc> We use CORBA to build bridge between C++ and Java.
Jun 02 17:22:52 <Cupu> Nice … so I should sharpen my java skills then :)
Jun 02 17:23:25 <beyonddc> I think the next guy on the road is Ruby on Rails
Jun 02 17:23:27 <J_K9> well, if you want to develop Navy systems… ;)
Jun 02 17:23:53 <J_K9> Rails is very good, but there are other good web-based platforms
Jun 02 17:24:09 <beyonddc> eh.. I don't know anything about web-based platforms
Jun 02 17:24:44 <Cupu> I left php a couple of years back .. I'm not really up2date on the web dev movement unfortunately :|
Jun 02 17:25:06 <J_K9> I'm still very much in it :)
Jun 02 17:25:26 <beyonddc> Regarding with the SRS and organizes the requirements in layer (version control, database, networking and etc). I think Jeff would be the good person to help on this.
Jun 02 17:25:43 <J_K9> yes, I have been in regular contact with him regarding this
Jun 02 17:25:55 <J_K9> according to him there is one step before that - Data Flow Diagramming
Jun 02 17:26:43 <J_K9> I believe he will soon be sending out an email about this and how we, as a team, will create diagrams for the data flow in the platform
Jun 02 17:26:57 <beyonddc> client utility → client infrastructure → network → server infrastructure → “destination”
Jun 02 17:27:09 <beyonddc> j/k
Jun 02 17:27:11 <J_K9> :P
Jun 02 17:27:13 <beyonddc> but that's actually the overall pic
Jun 02 17:27:22 <J_K9> from the client's end, yes
Jun 02 17:27:27 <Cupu> :))
Jun 02 17:27:30 <J_K9> but there's also message queues, etc ;)
Jun 02 17:27:37 <Cupu> hmmm
Jun 02 17:27:39 <beyonddc> that's….design max
Jun 02 17:27:45 <Cupu> isn't that dipping a little to much in the implementation?
Jun 02 17:27:49 <beyonddc> yup
Jun 02 17:27:58 <J_K9> hm
Jun 02 17:28:01 <beyonddc> in a requirement level, we don't need to talk about queue and stuffs
Jun 02 17:28:04 <Cupu> well I guess we have to start somewhere :D
Jun 02 17:28:06 <beyonddc> it's all functionality
Jun 02 17:28:09 <J_K9> true
Jun 02 17:28:30 <J_K9> I was talking about the messaging infrastructure - 'queue' was the wrong word to use at this point
Jun 02 17:29:03 <beyonddc> i think that's all part of networking layer.
Jun 02 17:29:17 <beyonddc> anything requires from point a to point b is networking layer
Jun 02 17:29:44 <J_K9> but where delayed messaging is concerned the networking layer will have to interface with, say, the database layer
Jun 02 17:30:07 <beyonddc> you can even argue the communication between the fd-client and fd-server will be using our own networking layer.
Jun 02 17:30:42 <beyonddc> yex max, again, that's up to the utility developer. They can pick a mixture of the network layer and database layer.
Jun 02 17:31:28 <beyonddc> basically it's like building Lego. We gave utility developer a set of lego, and they use their imgination to build what they want.
Jun 02 17:31:54 <J_K9> true, but the messaging is not a Utility. whether it uses the Utility API to function is yet to be decided
Jun 02 17:32:28 <beyonddc> okay
Jun 02 17:32:48 <beyonddc> i wouldn't argue for that for now. eh.
Jun 02 17:33:01 <J_K9> no, we can leave that till later
Jun 02 17:33:06 <beyonddc> yes
Jun 02 17:33:06 <clsk> i'm back
Jun 02 17:33:17 <J_K9> hi Alan :)
Jun 02 17:33:36 <beyonddc> hey alan…
Jun 02 17:33:45 <clsk> finally :|
Jun 02 17:33:48 <beyonddc> lol
Jun 02 17:33:52 <clsk> hm
Jun 02 17:33:53 <beyonddc> you live in an apartment?
Jun 02 17:34:08 <clsk> so can someone bring me up to speed of what you guys have been talking about?
Jun 02 17:34:11 <clsk> nop
Jun 02 17:34:13 <clsk> in the barracks
Jun 02 17:34:29 <beyonddc> we're on track on what we're providing is a set of API.
Jun 02 17:34:33 <clsk> kinda like an aparment building. But it's only rooms
Jun 02 17:34:42 <clsk> cool
Jun 02 17:34:52 <beyonddc> and that's basically it
Jun 02 17:35:04 <beyonddc> took us awhile to be on the same page
Jun 02 17:35:07 <clsk> olh
Jun 02 17:35:08 <clsk> oh
Jun 02 17:36:02 <clsk> hm
Jun 02 17:36:07 <beyonddc> and then we talked about that in the upcoming future, the requirements will be organized by layer.
Jun 02 17:36:13 <beyonddc> such as networking has its own set of requirement
Jun 02 17:36:20 <beyonddc> and version control has its own set of requirements
Jun 02 17:36:33 <clsk> what kind of requirements?
Jun 02 17:36:45 <beyonddc> that's to be discussed
Jun 02 17:37:03 <J_K9> and added to the SRS
Jun 02 17:37:08 <clsk> I mean. Are those API requirements?
Jun 02 17:37:14 <beyonddc> no Alan
Jun 02 17:37:16 <beyonddc> it's functionality
Jun 02 17:37:16 <clsk> What's the SRS?
Jun 02 17:37:23 <beyonddc> software requirement specification
Jun 02 17:37:24 <J_K9> Software Requirements Spec
Jun 02 17:37:28 <clsk> oh
Jun 02 17:37:41 <beyonddc> Alan, requirement just talks about functionality. The API and implementation is up to developer
Jun 02 17:37:51 <clsk> right
Jun 02 17:37:56 <clsk> got it
Jun 02 17:38:05 <clsk> so should we start discussing those requirements?
Jun 02 17:38:17 <J_K9> if you wish
Jun 02 17:38:29 <beyonddc> …
Jun 02 17:38:38 <beyonddc> I don't have time today.
Jun 02 17:38:45 <J_K9> ah, ok
Jun 02 17:38:47 <beyonddc> I need to go
Jun 02 17:38:52 <clsk> oh
Jun 02 17:38:53 <clsk> hm
Jun 02 17:38:57 <clsk> can we continue tomorrow?
Jun 02 17:38:58 <J_K9> perhaps on the mailing list then? shall we begin by discussing the requirements of the networking layer?
Jun 02 17:38:59 <beyonddc> It's Saturday afterall, and the sun is outside
Jun 02 17:39:16 <beyonddc> I can continue tomorrow
Jun 02 17:39:18 <Cupu> beyonddc: Yeah .. rub it in for us that can't leave :D
Jun 02 17:39:24 <beyonddc>
Jun 02 17:39:25 <J_K9> hehe :p
Jun 02 17:39:30 <clsk> I think this design thing is a bit too hard to do on the mailing list.
Jun 02 17:39:39 <J_K9> ok
Jun 02 17:39:44 <beyonddc> I can do it tomorrow at the same time
Jun 02 17:39:49 <beyonddc> if you guys can do it.
Jun 02 17:39:53 <J_K9> i'm ok with that
Jun 02 17:39:58 <clsk> me too
Jun 02 17:40:09 <Cupu> Definately .. I'm turning off my phones and dorbell for the tomorrow chat if it will happen
Jun 02 17:40:23 <beyonddc> okay… then that's the plan
Jun 02 17:40:27 <beyonddc> I am leaving now
Jun 02 17:40:28 <beyonddc> bye bye
Jun 02 17:40:31 <J_K9> Great! :) I'll send round an email on the list
Jun 02 17:40:35 <beyonddc> okay
Jun 02 17:40:38 <J_K9> Bye David, and thanks for joining us
Jun 02 17:40:39 <J_K9> :)
Jun 02 17:40:43 <beyonddc> no problem
Jun 02 17:40:44 <clsk> bye
Jun 02 17:40:46 * beyonddc (n=David@c-66-30-134-52.hsd1.ma.comcast.net) has left #mira
Jun 02 17:41:08 <clsk> so… now that he's gone. What are the requirements we want?
Jun 02 17:41:10 <clsk> :)
Jun 02 17:41:11 <clsk> just kidding
Jun 02 17:41:17 <J_K9> haha!
Jun 02 17:41:23 <Cupu> 
)
Jun 02 17:41:29 <J_K9> well, there's an overview of the requirements in the Definition Study
Jun 02 17:41:39 <J_K9> but we'll need to be more specific and explain them in the SRS
Jun 02 17:41:46 <clsk> yea, but that's a bit too broad
Jun 02 17:41:48 <J_K9> plus separate them as per layer, etc
Jun 02 17:41:53 <J_K9> yes, it is
Jun 02 17:41:54 <clsk> right
Jun 02 17:43:27 <J_K9> so do you all want to continue talking or shall we just think about the different subsystems and talk about them tomorrow?
Jun 02 17:45:01 <Cupu> I would go for option b .. since it's getting hectic in my part of the world :|
Jun 02 17:45:39 <J_K9> yes, and I should enjoy what's left of the sun ;)
Jun 02 17:45:57 <J_K9> it's been a good chat and I hope to see you guys here tomorrow!
Jun 02 17:46:45 <Cupu> sure thing .. same hour?
Jun 02 17:47:05 <J_K9> yes
Jun 02 17:47:16 <Cupu> great …!!
Jun 02 17:47:30 <J_K9> excellent! see you on here tomorrow then ;)
Jun 02 17:47:45 <Cupu> Have a good day !
Jun 02 17:48:01 <J_K9> And you! :) bye
Discussion