Developer Meeting 27/05/2007 15:00 UTC
Attendees: ananth, beyonddc, clsk, Cupu, J_K9
Note: All timestamps in UTC+1 (British Summer Time).
May 27 16:01:39 <J_K9> Hi guys. Ok, let's get this meeting started! :)
May 27 16:02:06 <clsk> I used threads on that same program before but decided not to later on.
May 27 16:02:11 <clsk> ok :)
May 27 16:02:26 <J_K9> Right. First of all, I think we should decide who will be working on which feature of the client and server apps, bearing in mind that there are a few developers missing.
May 27 16:03:38 <J_K9> For the lower-level functionality, we have the parser, networking implementation, Utilities API among other subsystems, as well as general management of either the Client or Server app
May 27 16:04:26 <J_K9> If you would like to work on a particular feature or app, please state so now :)
May 27 16:04:38 <Cupu> who's first :) ?
May 27 16:04:43 <clsk> you go first
May 27 16:04:45 <J_K9> anyone ;)
May 27 16:05:01 <beyonddc> um…
May 27 16:05:05 <clsk> I'd like to work on the server. Mainly the parser and networking implementation
May 27 16:05:08 <J_K9> we can work around your preferred feature to find one that will suit you anyway
May 27 16:05:10 <J_K9> ok
May 27 16:05:22 <clsk> and maybe management of the server devs
May 27 16:05:40 <J_K9> yes. next?
May 27 16:05:43 <Cupu> Ok .. so … besides the fact that I would like to pop a few questions (I guess there's time for that a little later) .. I would like to shoot for the Client part (GUI at first .. but really would like to get into the lower level client stuff)
May 27 16:05:48 <ananth> I'd like to work on the filesharing utility between the clients
May 27 16:06:13 <beyonddc> Well, I don't think we'll be doing any GUI at this time.
May 27 16:06:31 <beyonddc> It'll be all ground-level work to just to get the API working
May 27 16:06:35 <J_K9> Not quite yet - GUI work will begin once we've got the functionality in place
May 27 16:06:37 <clsk> well the client can start with a very simple GUI
May 27 16:06:38 <J_K9> indeed
May 27 16:06:39 <clsk> to test things
May 27 16:06:41 <Cupu> That's where my questions lie :)
May 27 16:06:52 <J_K9> ok, so what would you like to work on David?
May 27 16:07:16 <beyonddc> Not necessary, you might be just creating test drivers and input command thru parameters.
May 27 16:07:35 <beyonddc> I'm interesting in asio.
May 27 16:07:46 <J_K9> ok
May 27 16:07:52 <clsk> client or server side?
May 27 16:07:52 <Cupu> Can I throw a quick question?
May 27 16:08:03 <J_K9> go ahead
May 27 16:08:16 <beyonddc> um, any side is fine, eventually everyone will be an expert. If you work on server, I'll be working on client then
May 27 16:08:22 <J_K9> ok
May 27 16:08:25 <clsk> cool
May 27 16:08:47 <Cupu> Ok, although this was related to the GUI it applies on other parts as well. My udnerstanding is that regarding what libraries we'll use … in the long term we should be very flexible
May 27 16:08:49 <beyonddc> I think we need to rotate role on the way to ensure no single point of failure
May 27 16:09:22 <Cupu> That basically translates to me as an abstraction of such functionality as GUI,Networking,Threading etc.
May 27 16:09:26 <J_K9> There will of course be cross-collaboration, i.e. developers working on features which are not their own, perhaps to implement something which is needed in their own feature
May 27 16:09:28 <beyonddc> Yes, we need to be flexible
May 27 16:09:31 <clsk> well that's only like main roles. Everyone can check on eachother's code, etc…
May 27 16:09:37 <J_K9> and everyone should have a good knowledge of how the rest of the app works
May 27 16:09:38 <clsk> and add stuff to other people's code too.
May 27 16:09:40 <J_K9> yes
May 27 16:09:48 <J_K9> Cupu - I agree.
May 27 16:10:01 <beyonddc> Since we're not using ACE anymore, and will be using boost.
May 27 16:10:16 <beyonddc> I suggest that you can use boost anywhere in the code you want.
May 27 16:10:19 <J_K9> this is what we were discussing with wxWidgets, to abstract the GUI so that we could replace it if required
May 27 16:10:43 <clsk> yus, that's part of what I thought when I suggested we use boost.
May 27 16:10:44 <beyonddc> Yes, in particular, wxwidgets need to be abstracted for sure
May 27 16:10:46 <Cupu> I mean a thin layer above the actual libraries … even if they are abstract factories for the GUI or whatever applies, so that being said (again I take the GUI example) .. starting to write code now .. would yield results a lot later on; Example .. we will use wxWidgets .. but I will want to learn a little QT and GTK+ just so I can make some dummie test cases representing the GUI abstraction
May 27 16:11:14 <beyonddc> You can sure do that
May 27 16:11:26 <beyonddc> Don't overkill yourself for that though. ;x
May 27 16:11:38 <Cupu> I could round up a quick wxWidgets and MFC example .. but that's because they're so similar in some points. Anyway .. I'm writing to much .. just wanted to see if that's the way to go (the abstract way that is :) )
May 27 16:11:58 <beyonddc> Yes, that's the abstract way we want.
May 27 16:12:16 <beyonddc> Yea, boost is a good choice, assuming eventually it will be a c++ standard.
May 27 16:12:22 <Cupu> So yes I totally agree that building (as in displaying) GUI's is not the emergency right now and I want to channel my efforts in other areas if that's the general udnerstanding
May 27 16:12:27 <clsk> some of it will
May 27 16:12:38 <clsk> even asio was submitted for TR2
May 27 16:13:04 <clsk> so asio might become part of the standard too
May 27 16:13:10 <J_K9> right, so, to finalise the roles in terms of who will be working on what at first: clsk in charge of server, implementing networking and parsing functionality. Cupu working on the client-side equivalent along with deyonddc (particularly the networking and boost-relevant aspect). ananth working on the Files Utility, on the back-end at first and then the implementation with the Utilities API.
May 27 16:13:14 <J_K9> How does that sound?
May 27 16:13:19 <beyonddc> I would abstract asio though.
May 27 16:13:57 <beyonddc> What kind of file utilities?
May 27 16:14:08 <Cupu> There's one thing to note .. especially in the begining (as we lay the foundation) there is going to be a lot of code that will be shared by the server and the client (e.g. Filesystem abstraction, networking, etc.)
May 27 16:14:17 <J_K9> the Files Utility is like a version control utility
May 27 16:14:27 <beyonddc> Sure
May 27 16:14:31 <clsk> networking code will probably not be shared
May 27 16:14:36 <J_K9> yes, that's very true Cupu - particularly the parser and networking functionality, as they will need to interact
May 27 16:14:41 <clsk> maybe some, but not a whole lit.
May 27 16:14:44 <J_K9> ah, perhaps i was wrong
May 27 16:14:45 <J_K9> :)
May 27 16:14:54 <clsk> parser yes
May 27 16:14:57 <clsk> probably
May 27 16:15:02 <clsk> more than likely
May 27 16:15:08 * clsk shuts up
May 27 16:15:12 <J_K9> lol
May 27 16:15:13 <beyonddc> What I'm hoping for is not to dive into coding right away. Try to keep coding at minium. Once you've the concept ready, we'll peer-review it first.
May 27 16:15:21 <Cupu> clsk: Yes .. you're right .. I only meant at a very low level … let's think of the low level netweorking stuff as the Mira-Net-Abstraction .. that will be shared
May 27 16:15:49 <J_K9> we also need to bear in mind the P2P functionality, so the Client's networking developer will need to think about this
May 27 16:15:49 <Cupu> I apologies for my bad spelling (should have stated so in the start) .. it's the keyboard
May 27 16:16:04 <beyonddc> lol… blame it on the keyboard
May 27 16:16:06 <J_K9> lol
May 27 16:16:07 <Cupu> :)
May 27 16:16:15 <clsk> beyonddc: I agree with you in a way, but coding is the only way to test concepts. Code can always be re-written.
May 27 16:16:21 <J_K9> I agree with documenting *everything* first, by the way
May 27 16:16:32 <beyonddc> Yes, that's why I said try to keep it minimum to minimize your impact
May 27 16:16:35 <clsk> I think it'd just be good to keep in mind that most of the code will be re-written
May 27 16:16:38 <J_K9> but I do think we should start coding so that we can build on that as our documentation improves
May 27 16:16:39 <Cupu> clsk: Oh and even if we reduce it to the minimum .. there is going to be a lot of re-written code
May 27 16:16:57 <J_K9> indeed
May 27 16:17:23 <clsk> We need to get someone good at documenting.
May 27 16:17:27 <clsk> I'm pretty bad
May 27 16:17:30 <J_K9> by the way, I was contacted by a Lotus Notes developer who might be joining the mailing list to offer suggestions, so we may find that this helps with documenting and improving the groupware functionality
May 27 16:17:41 <J_K9> I'm quite good, but I need to know what I'm writing about
May 27 16:17:41 <Cupu> nice
May 27 16:17:46 <clsk> nice
May 27 16:18:13 <J_K9> so as long as the code is well commented and the ideas well documented (but not necessarily well written) I would be more than willing to adapt that
May 27 16:18:23 <clsk> J_K9: you should keep your blog going as it gives good publicity ;)
May 27 16:18:31 <clsk> keep the posts coming
May 27 16:18:33 <J_K9> I certainly will, clsk! ;)
May 27 16:18:44 <clsk> IIRC I first read about mira in slashdot or some place like that
May 27 16:18:50 <beyonddc> um… we need to look at how to use doxygen
May 27 16:18:53 <J_K9> I've just had a slight shortage of time recently with exams
May 27 16:18:59 <clsk> ah
May 27 16:19:02 <clsk> yea read about that.
May 27 16:19:06 <J_K9> yes, I believe it uses JavaDoc syntax
May 27 16:19:16 <clsk> school's been killing me lately too.
May 27 16:19:25 <J_K9> aye :)
May 27 16:19:27 <clsk> yes, I was thinking of that yesterday.
May 27 16:19:34 <clsk> I've never used before but need to learn
May 27 16:19:36 <J_K9> ok, here we go: http://java.sun.com/j2se/javadoc/writingdoccomments/
May 27 16:19:52 <J_K9> that's a good introduction to commenting code with JavaDoc comments, for those who have never used them before
May 27 16:19:53 <beyonddc> Are we talking about doxgen?
May 27 16:20:02 <clsk> yes
May 27 16:20:04 <beyonddc> http://www.stack.nl/~dimitri/doxygen/
May 27 16:20:38 <J_K9> does doxygen not parse JavaDoc syntax and write HTML documentation based on that?
May 27 16:20:53 <beyonddc> Not sure, I never use it before
May 27 16:20:56 <clsk> yuss
May 27 16:20:57 <beyonddc> I just *heard* about it
May 27 16:20:59 <Cupu> Well .. most probably yes
May 27 16:21:02 <clsk> that's pretty much all it does
May 27 16:21:03 <J_K9> ah, ok
May 27 16:21:10 <Cupu> But .. I made a note to self to look into doxygen :)
May 27 16:21:15 <beyonddc> And that's what we need anyway
May 27 16:21:18 <J_K9> great :)
May 27 16:22:02 <beyonddc> So let's talk a little about how many abstracted layer we'll have.
May 27 16:22:11 <J_K9> ok
May 27 16:22:19 <beyonddc> 1. GUI 2. Networking 3. File Utility?
May 27 16:22:20 <Cupu> Anybody logging this (I only started know .. also because of the keyboard .. I forgot )
May 27 16:22:22 <Cupu> ?
May 27 16:22:29 <clsk> 4. Directory back end
May 27 16:22:41 <J_K9> Cupu - I am
May 27 16:22:43 <clsk> for permissions
May 27 16:22:56 <clsk> I log all IRC conversations
May 27 16:23:04 <beyonddc> I would like to start this off from filebased first.
May 27 16:23:16 <beyonddc> Just to see if we can do this without a database.
May 27 16:23:28 <J_K9> beyonddc - the Files Utility is abstracted because of the Utilities API. All Utilities will use this API to implement additional functionality in an extension/plugin-like way
May 27 16:23:30 <clsk> hm
May 27 16:23:30 <beyonddc> deploying a database for a typical user is a pain.
May 27 16:23:32 <Cupu> Was it decided what storage backend we will be using? I mean .. will we also stay flexible in this remark .. as in files for now .. but maybe RDBMS later?
May 27 16:23:35 <clsk> Why?
May 27 16:23:40 <clsk> it doesn't have to be a database
May 27 16:23:51 <clsk> which is why we're using an abstraction layer
May 27 16:23:51 <J_K9> indeed
May 27 16:23:59 <J_K9> i think we should avoid databases
May 27 16:24:13 <Cupu> Right .. so a Filesystem abstraction can take care of a lot of this .. including permissions and the like
May 27 16:24:14 <clsk> pretty much the user will be able to use any database system, LDAP, or plain text files.
May 27 16:24:23 <J_K9> but store Workplace data (not necessarily Utlities data) in a place where it will not be modified by the user
May 27 16:24:32 <beyonddc> Yes I agree on that. Database layer could be a plugin
May 27 16:24:37 <Cupu> Be it over an actual filesystem or a database (which well .. is just on top of that also )
May 27 16:24:40 <clsk> What I was thinking of was a base Directory class and then add as many implementations as we want
May 27 16:24:55 <Cupu> clsk: Exactly
May 27 16:25:15 <beyonddc> We also need to investigate how to dynamically load shared library.
May 27 16:25:27 <clsk> I think boost has a library for that.
May 27 16:25:28 <Cupu> Right .. the plugin system
May 27 16:25:36 <clsk> but I think we should limit that only to Utilities
May 27 16:26:12 <beyonddc> The capability to load shared library will be perfect for the database layer.
May 27 16:26:23 <clsk> for the directory backend we can just make different classes and provide the option at compile-time AND run-time.
May 27 16:26:26 <beyonddc> To plug n play ldap layer, mysql layer, file based layer
May 27 16:26:52 <clsk> the reason why I say this is because administrators are not likely to change this very often
May 27 16:27:04 <clsk> and performance decreases with dlls
May 27 16:27:31 <Cupu> I don't know .. is that so significant lately?
May 27 16:27:38 <beyonddc> As long as it's reasonable, I think a slight performance hit is OK
May 27 16:27:40 <Cupu> Load time performance will sufer of course
May 27 16:27:46 <Cupu> but … other than that …
May 27 16:27:59 <J_K9> If I may shortly return to the data storage problem, how about storing all Workplace data in the user's home directory under the directory Workplaces? The data of each Workplace will be stored in the '$server-$workplace' directory within Workplaces, other settings in '$server-$workplace/config' and all Utility-specific data within that Workplace in '$server-$workplace/$utility'
May 27 16:28:09 <ananth> dlls will make load time faster, but its the run time that will be hit
May 27 16:28:26 <clsk> exactly anath
May 27 16:28:40 <beyonddc> How much of an impact?
May 27 16:28:42 <Cupu> ananth: I think it's the other way around .. presuming they're also loaded at the start
May 27 16:28:51 <Cupu> Actually I should rephrase
May 27 16:28:51 <beyonddc> That's what I'm thinking
May 27 16:29:03 <beyonddc> You load your library during start-time
May 27 16:29:04 <clsk> Cupu: no, because the library is not loaded until it's needed.
May 27 16:29:07 <Cupu> Loading a shared lib as opposed to having it staticly linked in .. is going to take longer
May 27 16:29:10 <ananth> For the workplace storage, if we use the SVN (for example), it provides its own filesystem abstraction
May 27 16:29:22 <Cupu> But that's the only performance loss .. when it's loaded
May 27 16:29:49 <ananth> no, loading a shared will be faster. it loads the reqd functions at run time, thats why run time will be slower
May 27 16:29:51 <Cupu> Presuming people don't do anything but load/unload .. we should be ok
May 27 16:30:13 <J_K9> ananth - but on the client's side, if they edited file outside of Mira the Mira Client would then need to detect the change and sync it accordingly. we would have to tie in Utility data storage with SVN though
May 27 16:30:44 <beyonddc> Ananth, I think we need to provide another wrapper ontop of the SVN wapper so we can switch and swap if we want to change from SVN to CVS or etc.
May 27 16:31:22 <Cupu> I'll re-rephrase … Loading a shared lib. (as opposed to having it already loaded with the executable) will take a bit longer. Once the libs are loaded (static or not) there is no runtime difference between the two
May 27 16:31:47 <beyonddc> Stefen, that's what I'm thinking.
May 27 16:31:51 <J_K9> The problem is that we will probably need to settle on a certain backend to handle this… If we were to build everything else on top of it and then change the foundations (i.e. SVN, for example), it would all collapse unless we had gone a long way to abstract it
May 27 16:32:23 <Cupu> I fear we need to go the long ways for all abstractions
May 27 16:32:28 <J_K9> that is true
May 27 16:32:32 <beyonddc> Max, that's why the architecture is very important at this point. We need to be very careful on how to abstract each layer.
May 27 16:32:36 <J_K9> indeed
May 27 16:32:36 <Cupu> if we want a lot of flexibilities
May 27 16:32:42 <J_K9> which is why we need to begin documenting it
May 27 16:33:02 <beyonddc> We do need a lot of flexiblity, that's what I'm thinking.
May 27 16:33:03 <J_K9> that way we change the design as we discover new ways of doing things
May 27 16:33:18 <beyonddc> Yup, I agree with you Max
May 27 16:33:52 <Cupu> Same here
May 27 16:33:57 <J_K9> ok, so the best thing I believe is for someone to create a rough skeleton of the architecture on the wiki over the next few days and for the rest of us to improve on it
May 27 16:34:27 <beyonddc> By next Sunday, I suggested
May 27 16:34:29 <clsk> can someone explain the difference of sending text and files over a socket?
May 27 16:34:36 <ananth> Cupu: when an executable is statically linked with a lib, it knows where to look for at run time, so run time will be faster, but at the same time ,the executable will be heavier, so load time is slower
May 27 16:34:49 <clsk> I've never done anything that sent files over the network.
May 27 16:35:01 <J_K9> beyonddc - I agree. Let's use this week productively to document the architecture as comprehensively as possible
May 27 16:35:19 <Cupu> ananth: Couldn't agree more .. i was only stressing that after loading .. the perfomance is identical
May 27 16:35:23 <beyonddc> Alan, I never done that also.
May 27 16:35:45 <beyonddc> Google will be your friend
May 27 16:35:48 <clsk> I know the basics
May 27 16:36:01 <J_K9> by the way, I will be using the coming week to make as many mockups of other windows (e.g. the messaging window) as possible
May 27 16:36:29 <J_K9> that should spark up some good ideas for the functionality and will hopefully help with the documentation of the underlying architecture to allow it to operate
May 27 16:36:33 <beyonddc> Alan, I think it might be as simple as converting the file into a byte stream.
May 27 16:36:49 <clsk> That's what I thought too.
May 27 16:36:54 <clsk> hm got a question.
May 27 16:36:59 <clsk> Do we really want to use the GPL?
May 27 16:37:08 <J_K9> Why?
May 27 16:37:13 <beyonddc> I'm not familiar with license.
May 27 16:37:15 <J_K9> or, rather, why not? :)
May 27 16:37:17 <Cupu> beyonddc: That's basically it
May 27 16:37:18 <clsk> just asking
May 27 16:37:29 <clsk> I have no problem.
May 27 16:37:34 <clsk> just throwing the question out there
May 27 16:37:38 <J_K9> It's an open licence which will allow others to share and improve upon the code but not without releasing their improvements
May 27 16:37:55 <ananth> Cupu: I dont think so, run time is slower with shared and dyn loaded libs
May 27 16:38:00 <clsk> hm, what about forking? Do we want other people to fork our project?
May 27 16:38:08 <J_K9> by the way, i did contact a FOSS lawyer about this and he suggested GPL for it
May 27 16:38:25 <J_K9> clsk - no, and that's something i was worrying about
May 27 16:38:44 <J_K9> as well as other people selling compiled versions of our code under other names, as happened a few years ago with Luxuriosity
May 27 16:38:51 <clsk> if we don't want people to fork our project then we should think about using another license.
May 27 16:39:02 <ananth> Alan: sending text files is same as sending text. but i dont know about binary, on UNIX atleast it might be same
May 27 16:39:14 <beyonddc> ananth, I'll spend a little time this week to do some investigation about dynamically loaded library.
May 27 16:39:15 <J_K9> let's discuss the licence on the mailing list :)
May 27 16:39:32 <Cupu> ananth: It usually is just a single level of indirection … I don't think we'll take a hit
May 27 16:39:53 <clsk> J_K9: I think that's something we need to start thinking before I put code on the svn.
May 27 16:40:00 <clsk> btw I need to learn how to use svn as I
May 27 16:40:03 <J_K9> clsk - yes, definitely
May 27 16:40:04 <clsk> btw I need to learn how to use svn as I've only used CVS
May 27 16:40:12 <beyonddc> same here, I never use svn and cvs
May 27 16:40:15 <J_K9> svn is very similar - it uses almost the same commands
May 27 16:40:17 <beyonddc> at work, I use clear case.
May 27 16:40:20 <J_K9> i'll send round a guide for it
May 27 16:40:22 <clsk> cool
May 27 16:40:44 <J_K9> plus i think i put something about it on the wiki, but I'll improve that :)
May 27 16:41:21 <beyonddc> Is there's file interoperability problem between linux and windows?
May 27 16:41:34 <J_K9> would anyone be interested in making the SVN skeleton for the project after this, or should we wait till we've documented the architecture?
May 27 16:41:48 <J_K9> beyonddc - what, encoding-wise?
May 27 16:41:56 <beyonddc> Yea, encoding
May 27 16:42:12 <J_K9> I don't think that should be a problem as long as we use a particular one consistenly, e.g. UTF-8
May 27 16:42:13 <clsk> beyonddc: not really
May 27 16:42:30 <beyonddc> SVN skeleton? I thought Ananth is working on the file utility.
May 27 16:42:36 <beyonddc> Or you're talking about something else?
May 27 16:42:42 <J_K9> something else
May 27 16:42:43 <Cupu> Also we need to take care not to mess up file nameing (as in case) between *nixes and msw
May 27 16:42:45 <clsk> J_K9: I think someone should do the skeleting as I plan on starting coding today or tomorrow.
May 27 16:42:47 <ananth> SVN skeleton for storing our code, right?
May 27 16:42:50 <J_K9> the skeleton is just the directory setup
May 27 16:42:53 <beyonddc> ohhh
May 27 16:42:58 <J_K9> yes
May 27 16:43:25 <J_K9> we will need to create directories according to the structure of the app, however.
May 27 16:43:35 <beyonddc> um…
May 27 16:43:46 <J_K9> hehe, just what I thought :)
May 27 16:44:06 <beyonddc> I can talk about the file structure of my work environment as an example.
May 27 16:44:10 <J_K9> please do
May 27 16:44:31 <beyonddc> mira ←- root directory
May 27 16:44:44 <beyonddc> inside mira, there'll be couple of folders.
May 27 16:44:50 <beyonddc> build, src
May 27 16:44:54 <J_K9> test?
May 27 16:45:00 <clsk> include
May 27 16:45:03 <beyonddc> build, src, bin
May 27 16:45:20 <beyonddc> I'm trying to think on top of my head right now.
May 27 16:45:30 <J_K9> include within src, is it not?
May 27 16:45:44 <beyonddc> yes, the includes are in src
May 27 16:45:53 <Cupu> :) Right .. not meaning to pass responsability along .. but .. someone could make a little model and we'll improve on that in the mailing list
May 27 16:46:00 <beyonddc> within the build folder, there's a master makefile
May 27 16:46:03 <J_K9> sure
May 27 16:46:04 <beyonddc> okay, I'll do that Max
May 27 16:46:16 <J_K9> ok, great - we'll then discuss it from there! :)
May 27 16:46:27 <beyonddc> I'll do it right after the meeting
May 27 16:46:27 <Cupu> Could we though first separate client and server under mira … (each with thei src and so on .. )
May 27 16:46:35 <beyonddc> yes we'll
May 27 16:46:36 <J_K9> oh yes
May 27 16:46:47 <J_K9> on another note, we'll need a bug tracker - Bugzilla or Trac?
May 27 16:46:52 <Cupu> separate folder for tools and so one
May 27 16:46:56 <J_K9> yes
May 27 16:47:11 <beyonddc> I'll try to come up with a complete layout and we can talk more on e-mail
May 27 16:47:39 <Cupu> (I have to get an english speaking keyboard) .. I haven't used any of the bug tracking systems .. so we could go for what's more popular as far as I'm concerned
May 27 16:47:43 <ananth> sourceforge has a bug tracking tool too, i think
May 27 16:47:52 <J_K9> yes, but it's not that advanced i believe
May 27 16:47:57 <J_K9> Bugzilla is probably the most popular
May 27 16:48:04 <J_K9> it's been around for a long time as well
May 27 16:48:05 <ananth> oh, ok
May 27 16:48:18 <J_K9> although if SF's bug tracker will do, then perhaps we could use that
May 27 16:48:21 <beyonddc> Max, are you familiar with SVN?
May 27 16:48:39 <J_K9> it's up to you guys - if you're more comfortable with Bugzilla (there should be a demo somewhere) then please let me know
May 27 16:48:41 <J_K9> yes, I am
May 27 16:48:45 <clsk> I started a layout for the server
May 27 16:48:52 <clsk> but it's not complete of course.
May 27 16:48:57 <J_K9> great :)
May 27 16:49:10 <beyonddc> So after we agree upon on the SVN structure, can you go ahead and create that in SVN?
May 27 16:49:19 <J_K9> certainly :)
May 27 16:49:46 <beyonddc> Can we talk about expectation for next week?
May 27 16:49:52 <J_K9> yes
May 27 16:49:59 <beyonddc> Just to summarize what we talked about
May 27 16:50:42 <beyonddc> So from what I heard, by next Sunday, each of us who's working on a task will need to provide documentation on wiki on the arthitecture layout.
May 27 16:50:50 <J_K9> Yes
May 27 16:50:53 <beyonddc> and we'll peer review it
May 27 16:50:54 <clsk> J_K9: Is that dev box you offered still available?
May 27 16:50:59 <J_K9> clsk - yes
May 27 16:51:07 <J_K9> yes, peer review is, of course, required
May 27 16:51:14 <clsk> I think I'm going to need it.
May 27 16:51:23 <clsk> After all I am going to Iraq
May 27 16:51:29 <J_K9> we will also all have a duty to document the overall architecture as fully as possible
May 27 16:51:44 <clsk> which by the way means I won't be available for about a month or two starting the second week of july.
May 27 16:51:48 <beyonddc> Alan will be working on server in general. Stefan and myself will be working on client/GUI. Ananth will be working on file utility
May 27 16:52:04 <J_K9> ah, right - yes, i'll set it up next week, and that's not a problem. whenever you can help is fine :)
May 27 16:52:43 <J_K9> David - That's right. I will be making mockups and writing the documentation for now and the near future.
May 27 16:52:48 <beyonddc> And then abstraction layer so far is the following 1. GUI 2. Networking 3. File Utility 4. Database
May 27 16:53:05 <J_K9> Is the Files Utility really abstracted?
May 27 16:53:19 <Cupu> You guys think there's anyway we could integrate file and database in the same abstraction?
May 27 16:53:23 <beyonddc> If we want to switch from SVN to CVS
May 27 16:53:24 <J_K9> I think it's the Utility API which is implemented and then *all* Utilities are abstracted
May 27 16:53:38 <J_K9> Cupu - in what sense?
May 27 16:53:55 <J_K9> the database to maintain the structure of file and folders and information on each?
May 27 16:54:13 <ananth> actually, CVS doesnt provide its own API like SVN does
May 27 16:54:26 <beyonddc> 
I didn't know that Ananth. eh
May 27 16:54:28 <Cupu> well .. we're talking about storage backends .. could we locate everything in the same place .. storage, permissions, security and all other check's
May 27 16:54:35 <Cupu> that is .. unless I missed File's point :)
May 27 16:54:50 <J_K9> no, that's right… but I've just realised a big problem with that
May 27 16:54:54 <J_K9> well, not a big one
May 27 16:54:54 <clsk> Cupu: I think it'll be better to separate those.
May 27 16:54:55 <ananth> so, for CVS the abstraction has to call scripts
May 27 16:55:00 <beyonddc> I think what we talked so far, the database layer is purely for user information
May 27 16:55:02 <J_K9> it could be solved by the server
May 27 16:55:30 <Cupu> I see, so that's what I missed .. I thought we could use it as a universal storage too
May 27 16:56:06 <beyonddc> We could do that too if we want to.
May 27 16:56:10 <J_K9> say a user doesn't have permissions to delete a file but DOES outside Mira, the Mira Client would have to recognise this, send the new layout to the server, the server send back a no-permissions error with precise information followed by the data which should not have been deleted/edited/etc depending on permissions
May 27 16:56:22 <beyonddc> The database layer can talk directly to the file utility layer.
May 27 16:56:40 <J_K9> The database layer could talk to all Utilities to manage their information - that's an excellent idea
May 27 16:57:21 <beyonddc> Ananth, what's your thought?
May 27 16:57:46 <ananth> yes, i agree
May 27 16:58:01 <J_K9> but we will need to implement the Utilities API in such a way that we allow the Utility to interact with the database in a non-destructive way (i.e. create a table with the name of the Utility within a database for that Workplace, for example?)
May 27 16:58:06 <beyonddc> I just think we need at minimum a generic wrapper ontop of SVN to increase flexiblity.
May 27 16:58:17 <J_K9> beyonddc, that is definitely going to be required
May 27 16:58:22 <beyonddc> okay
May 27 16:58:35 <beyonddc> what exactly are the utilities you're talking about Max
May 27 16:58:38 <J_K9> I foresee quite a bit of modification and tweaking to SVN's APIs to get this to work :)
May 27 16:58:40 <beyonddc> I think I'm a little confuse there
May 27 16:58:50 <J_K9> well, the ones in the mockups and whichever others people can think of
May 27 16:59:02 <beyonddc> like messaging, white board and etc?
May 27 16:59:03 <J_K9> e.g. Files, Polls, Notes, Discussion Forums, etc
May 27 16:59:05 <J_K9> yes
May 27 16:59:08 <beyonddc> okay
May 27 16:59:24 <J_K9> (messaging = instant messaging board, I presume?)
May 27 16:59:34 <beyonddc> so that's different than what's ananth is working on, right?
May 27 16:59:51 <J_K9> Ananth is working on the backend to make that all happen
May 27 16:59:55 <ananth> one more thing, does mira have to deal with the files other than the workspace?
May 27 16:59:55 <beyonddc> Yes
May 27 17:00:00 <J_K9> which is probably one of the most difficult features
May 27 17:00:15 <clsk> instant messaging should probably part of the core application
May 27 17:00:21 <clsk> I mean that should be built-in
May 27 17:00:23 <clsk> like in groove.
May 27 17:00:30 <Cupu> definately
May 27 17:00:31 <J_K9> ananth - Mira has to deal with the Utilities and their data… so it will have to deal with text information and also files)
May 27 17:00:48 <J_K9> clsk - so as in the mockups rather than a separate Utility?
May 27 17:00:57 <clsk> yes
May 27 17:00:59 <J_K9> ok
May 27 17:01:09 <ananth> ok
May 27 17:01:23 <beyonddc> Sure
May 27 17:01:40 <J_K9> we will need to discuss this data storage mechanism in depth, so perhaps we should leave it for the mailing list?
May 27 17:01:50 <clsk> yes
May 27 17:01:53 <J_K9> ok
May 27 17:02:09 <beyonddc> Okay
May 27 17:02:15 <clsk> hm
May 27 17:02:23 <clsk> another thing I was wondering about…. Patents.
May 27 17:02:34 <beyonddc> Max, what happened to project manager?
May 27 17:02:34 <Cupu> that word scares me
May 27 17:02:35 <clsk> we need to make sure we don't violate any groove patents (if they have any)
May 27 17:02:47 <J_K9> clsk - that's true
May 27 17:02:54 <J_K9> beyonddc, what do you mean?
May 27 17:03:09 <beyonddc> oh, just asking why he's not here today, eh
May 27 17:03:12 <J_K9> we'll need to find out what patents were filed under Groove's name
May 27 17:03:37 <clsk> I thought Max was the project manager?
May 27 17:03:40 <ananth> who is the PM?
May 27 17:03:41 <J_K9> oh, no, Hari has been a huge help with the forum and is in charge of that.
May 27 17:03:42 <clsk> I'm rather confused.
May 27 17:03:44 <J_K9> I am the PM
May 27 17:03:44 <ananth> i thought so too
May 27 17:04:19 <clsk> hm
May 27 17:04:24 <clsk> we should probably introduce ourselves
May 27 17:04:26 <beyonddc> oo… support manager i mean
May 27 17:04:28 <Cupu> :D
May 27 17:04:32 <J_K9> hehe! yes :D
May 27 17:04:33 <clsk> Although that would've been more convenient in the beginning.
May 27 17:04:33 <beyonddc> Hari
May 27 17:04:39 <Cupu> right .. I got confused there for a second
May 27 17:04:48 <J_K9> clsk, I agree entirely ;)
May 27 17:04:53 <J_K9> ok, no probs
May 27 17:05:25 <J_K9> to return to the patent issue, software patents are a very flaky issue… they are not considered true patents in many countries but we'll need to make sure that we don't step on any toes
May 27 17:05:53 <beyonddc> right
May 27 17:05:54 <Cupu> well
May 27 17:05:57 <J_K9> but there ARE many other groupware solutions out there (mostly web-based) which use similar technologies
May 27 17:06:09 <Cupu> sincerely .. In groove's case … there is certanly a precedent
May 27 17:06:19 <J_K9> yes
May 27 17:06:21 <J_K9> that is true
May 27 17:06:35 <Cupu> What I mean is .. unless we take feature's names … I don't think we can stumble upon new and groundbraking technology
May 27 17:06:36 <clsk> still, we don't have the money to go to court to debate that ;)
May 27 17:06:51 <Cupu> If there are patents in this area .. they don't belong to MS (or at least not on Groove's part)
May 27 17:07:04 <J_K9> Cupu - yes, and we do have different names for almost everything. I was careful with that from the start :)
May 27 17:07:07 <Cupu> clsk: Right .. if that happens I'm changing my email address
May 27 17:07:08 <Cupu> :)
May 27 17:07:10 <J_K9> lol
May 27 17:07:17 <clsk> heh
May 27 17:07:37 <ananth> :))
May 27 17:07:44 <Cupu> A good point non the less .. I hope I'll find the courage to step into that jungle and try to take a look next week
May 27 17:08:02 <J_K9> indeed
May 27 17:08:08 <clsk> when do you guys plan on start coding?
May 27 17:08:09 <J_K9> I will also try to find out whatever I can
May 27 17:08:44 <beyonddc> eh… have fun. I'll stick with my developer role
May 27 17:08:46 <J_K9> by the way guys, we're going to need to create a contributor's agreement together which everyone will need to agree to before contributing code to Mira
May 27 17:08:46 <Cupu> clsk: Whenever the group agrees to it … I'd start now (after a ciggarette that is) .. but that might not be the best idea :)
May 27 17:08:56 <Cupu> beyonddc: Envy arises in my heart :D
May 27 17:08:59 <beyonddc> 
May 27 17:09:05 <J_K9> lol
May 27 17:09:38 <Cupu> we really got in to the nasty stuff here :D .. well I'll sign (virtually or not) anything as long as I don't have to sell a kidney
May 27 17:09:38 <clsk> heh
May 27 17:09:39 <J_K9> The contributor agreement is just so that we don't get an external contributor adding some extremely core code and then deciding to pull it out in 2 years :P
May 27 17:10:09 <clsk> that should be part of the license.
May 27 17:10:10 <Cupu> :)
May 27 17:10:22 <clsk> and every contribution should be under that license.
May 27 17:10:25 <ananth> everything is going to be under GPL (or something like that), so is that reqd?
May 27 17:10:29 <Cupu> clsk: Actually that's a little more group oriented .. the license is for everyone
May 27 17:10:40 <J_K9> indeed
May 27 17:10:46 <J_K9> there's a different between the agreement and the licence
May 27 17:10:48 <Cupu> I don't want to call it internap company policy :))
May 27 17:10:49 <clsk> still that person can't just pull it out.
May 27 17:10:49 <J_K9> *difference
May 27 17:10:54 <Cupu> *internal (damn keyboard)
May 27 17:11:05 <beyonddc> sure Stefen, blame it on the keyboard again
May 27 17:11:08 <J_K9> clsk - they can if they maintain copyright of the work
May 27 17:11:11 <J_K9> lol
May 27 17:11:16 <clsk> oh
May 27 17:11:22 <Cupu> Hey .. I've been doing it for years … no sense in breaking a good habit
May 27 17:11:24 <J_K9> at least, I believe so
May 27 17:11:32 <clsk> then the group should maintain the copyright
May 27 17:11:36 <J_K9> yes
May 27 17:11:37 <clsk> I see what you mean now.
May 27 17:11:40 <J_K9> I've got a draft agreement btw
May 27 17:11:44 <beyonddc> Right… just like a software bug is not actually a bug, but instead it is a feature
May 27 17:11:58 <beyonddc>
May 27 17:11:58 <Cupu> clsk: That might cause fear in the users (Or let's say integrators)
May 27 17:12:11 <Cupu> beyonddc: :D exactly my motto for years
May 27 17:12:19 <J_K9> I'll upload it to the wiki so that you can all comment on it and, if we're all in agreement, accept, sign and make the final version public etc :)
May 27 17:12:28 <Cupu> Great!
May 27 17:12:44 <J_K9> beyonddc - haha! :D
May 27 17:12:44 <beyonddc> k
May 27 17:13:21 <clsk> beyonddc: you'd be surprised, but I've seen bugs become handy
May 27 17:13:23 <clsk> heh
May 27 17:13:28 <Cupu> :)
May 27 17:13:28 <J_K9> hehe
May 27 17:13:33 <beyonddc> eh
May 27 17:13:44 <beyonddc> what ever happened to the little introduction?
May 27 17:13:50 <beyonddc> I'm David from Boston
May 27 17:14:03 <J_K9> I'm Max from Gibraltar, currently at college in the UK
May 27 17:14:08 <ananth> Ananth from Bangalore, India
May 27 17:14:16 <Cupu> Stefan for Bucharest, Romania
May 27 17:14:21 <Cupu> *from (yes I know)
May 27 17:14:24 <beyonddc> wow Ananth, are you sleepy yet?
May 27 17:14:39 <ananth> yep, was planning to say goodbye
May 27 17:14:41 <ananth> :)
May 27 17:14:46 <J_K9> wow, it must be late - i'm sorry about that Ananth!
May 27 17:14:59 <clsk> I'm Alan from the Dominican Republic, but living in Oklahoma
May 27 17:15:01 <J_K9> thank you enormously for attending this :)
May 27 17:15:02 <clsk> and I call Florida home
May 27 17:15:07 <ananth> no problem at all.
May 27 17:15:23 <ananth> wow, a truly international team!
May 27 17:15:24 <J_K9> and now that we all know each other… hello to all ;)
May 27 17:15:28 <J_K9> indeed!
May 27 17:15:36 <Cupu> Heh .. I'd very much want to take everybody out for a beer now .. but as it seems .. that's not really possible
May 27 17:15:45 <ananth> :)
May 27 17:15:48 <beyonddc> Is there's anyone in here who's underage?
May 27 17:15:48 <J_K9> hehe, same here
May 27 17:15:58 <ananth> Max, how many have not attented this meeting?
May 27 17:16:00 <J_K9> I would be by UK standards
May 27 17:16:06 <clsk> 18 here
May 27 17:16:08 <clsk> I mena
May 27 17:16:08 <beyonddc> What's UK standards?
May 27 17:16:09 <clsk> lol
May 27 17:16:10 <clsk> 22
May 27 17:16:11 <J_K9> Ananth - 2, I think
May 27 17:16:11 <clsk> not 18
May 27 17:16:12 <Cupu> 21
May 27 17:16:20 <ananth> lol, nope
May 27 17:16:28 <ananth> 24
May 27 17:16:37 <J_K9> yes, Daryl's missing and Bart if he decides to join us :)
May 27 17:16:38 <clsk> how old are you guys?
May 27 17:16:47 <clsk> Daryly popped up last night
May 27 17:16:52 <clsk> he said he wasn't going to be able to attend
May 27 17:16:57 <Cupu> Right .. this reminds me of the hype hosting comanies had in the boom “A yound dynamic team of specialists” :)
May 27 17:17:01 <beyonddc> And ntgn81?
May 27 17:17:01 <J_K9> ah, ok
May 27 17:17:02 <J_K9> lol
May 27 17:17:09 <beyonddc> I'm 25
May 27 17:17:12 <J_K9> ah, yes, indeed - that makes 3 missing :)
May 27 17:17:13 <clsk> <clsk> so what part of mira are you thinking of working on?
May 27 17:17:14 <clsk> <radlyeel> I suppose I'll find out after tomorrow's chat, which I can't attend. :) I suspect the “packaging,” since I told Max I was interested in portable programming issues.
May 27 17:17:14 <clsk> <radlyeel> I'm busy learning wxWidgets, pretty much from scratch.
May 27 17:17:14 <J_K9> I'm 16. I hope you think no less of me for that!
May 27 17:17:21 <ananth> Max, why 2?
May 27 17:17:43 <J_K9> I thought two were missing - it appears that 3 are.
May 27 17:18:02 <ananth> i mean why did u think i was 2 yrs? :)
May 27 17:18:11 <J_K9> haha! I did not… ;)
May 27 17:18:15 <Cupu> Oh .. definately not drinking age
May 27 17:18:16 <ananth> oh, ok i got it
May 27 17:18:18 <beyonddc> Portable programming shouldn't be that hard as long as all libraries we're using is portable.
May 27 17:18:19 <ananth>
May 27 17:18:22 <J_K9> Cupu, it is in Gibraltar ;)
May 27 17:18:30 <Cupu> :)
May 27 17:18:51 <Cupu> and to think of all those years of ilegal drinking .. I could have just relocated
May 27 17:19:06 <J_K9> haha! yes, but that might have been a bit more difficult! :D
May 27 17:19:13 <beyonddc> Hey, can we briefly sum up what compiler we'll be using for windows and linux platform for now. We talked about it on mailing list.
May 27 17:19:22 <beyonddc> is it gcc for sure?
May 27 17:19:40 <clsk> gcc for linux
May 27 17:19:46 <beyonddc> what about windows?
May 27 17:19:49 <J_K9> gcc is fine by me - it is almost the Open Source standard
May 27 17:19:53 <Cupu> I think we can use whatever we want for isolated dev stuff .. as long as we don't try to use VC's dll's with a gcc build and wonder why they don't work :)
May 27 17:20:06 <beyonddc> well… we need to put build script in SVN
May 27 17:20:10 <J_K9> ah
May 27 17:20:13 <clsk> although
May 27 17:20:20 <J_K9> then what about gcc and MingW?
May 27 17:20:22 <Cupu> Anyone on 64-bit machines?
May 27 17:20:28 <Cupu> Mingw sounds great
May 27 17:20:31 <beyonddc> That's what I'm hinking. gcc and mingw
May 27 17:20:44 <clsk> we should be using standard c++ which should be able to compile in any compiler.
May 27 17:20:53 <J_K9> indeed
May 27 17:21:00 <clsk> I normally use visual c++ when in windows.
May 27 17:21:21 <J_K9> by the way, when building for other OSs I presume we'll just be changing the build flags?
May 27 17:21:33 <beyonddc> Why I'm suggesting gcc and mingw is because I assume we can use a single build script for both platform
May 27 17:21:37 <Cupu> clsk: hopefully ..I have gcc4.something … and I know that at least in templates it has stricter scope/naming requirements
May 27 17:21:52 <clsk> hm
May 27 17:21:58 <Cupu> but .. with a little bit of care .. we should pull it off easily
May 27 17:22:04 <clsk> yuss
May 27 17:22:11 <J_K9> great
May 27 17:22:20 <Cupu> The only thing I want to beg everybody .. don't use VC 6.0 or lower
May 27 17:22:31 <beyonddc> I got no VC
May 27 17:22:35 <J_K9> neither do I
May 27 17:22:36 <ananth> me too
May 27 17:22:38 <Cupu> pure evil lurks there
May 27 17:22:38 <beyonddc> mingw will be my friend
May 27 17:22:47 <Cupu> we could do fine with the express edition if needed ..
May 27 17:22:52 <ananth> Cygwin for me on windows
May 27 17:22:53 <Cupu> right .. so mingw it is then ?
May 27 17:22:59 <J_K9> I guess that's a yes :)
May 27 17:23:03 <Cupu> great!
May 27 17:23:17 <beyonddc> Cygwin is probably slower compare with mingw
May 27 17:23:24 <J_K9> yes
May 27 17:23:34 <ananth> yes, but most of the time, i'll be using Linux
May 27 17:23:45 <Cupu> ananth: that's the way to go ;)
May 27 17:23:50 <ananth> :)
May 27 17:23:57 <J_K9> Linux user here too :)
May 27 17:24:07 <beyonddc> Anyway, how about this…. mingw+gcc or visual studio express w/ ms c++ compiler for windows
May 27 17:24:12 <beyonddc> and gcc for linux
May 27 17:24:22 <Cupu> let's go gcc all the way
May 27 17:24:24 <clsk> yea there's no reason to use vc6 or lower
May 27 17:24:26 <J_K9> ok
May 27 17:24:30 <clsk> visual c++ express is free
May 27 17:24:36 <J_K9> then gcc on *nix and mingw on Windows?
May 27 17:24:41 <Cupu> but we'll also provide custom project files for MS VC++ (visual studio if you will)
May 27 17:24:50 <beyonddc> that sounds good to me
May 27 17:25:16 <J_K9> unless some want to use one of MS' suite.. although I don't know how much of a difference that would make
May 27 17:25:30 <clsk> none at all
May 27 17:25:33 <J_K9> ok
May 27 17:25:36 <clsk> except of the build script
May 27 17:25:36 <Cupu> great
May 27 17:25:42 <J_K9> ah
May 27 17:25:51 <beyonddc> Yea, like Stefen said, we'll provide build files for visual studio also
May 27 17:25:51 <Cupu> well .. we'll provide that too .. but that's so far away that I'm afraid to open my eyes :)
May 27 17:26:00 <J_K9> hehe! yes
May 27 17:26:29 <J_K9> ok, so we've now decided on compilers
May 27 17:26:33 <J_K9> clsk, I'll set up that server on wednesday - will that be ok?
May 27 17:27:03 <clsk> yuss
May 27 17:27:06 <clsk> sounds good.
May 27 17:27:14 <J_K9> ok
May 27 17:27:17 <Cupu> I'm sorry to say this .. but I really must get out in a few minutes or so :|
May 27 17:27:23 <clsk> I have a shell on a box right now. I'll start writing on that one for now.
May 27 17:27:28 <J_K9> ok
May 27 17:27:29 <Cupu> Hate to do this though
May 27 17:27:41 <J_K9> Cupu - not a problem. we have the mailing list for this very reason :)
May 27 17:27:46 <ananth> me too, have to go now, see u all next week
May 27 17:27:49 <J_K9> indeed
May 27 17:27:58 <beyonddc> One last thing
May 27 17:27:59 <J_K9> just to recap
May 27 17:28:16 <clsk> Lets put everybody's roles on the wiki
May 27 17:28:20 <Cupu> However .. I'll eave this open so that I can read the disscution .. I also want to say .. if anyone wants to ping me at (mostly anytime) I use IM: yahoo: cupubboy MSN: [PROTECTED] ICQ: I have no idea … so feel free to ping
May 27 17:28:22 <clsk> main roles that is.
May 27 17:28:30 <J_K9> to be discussed on the mailing list: licence, contributor agreement, Workplace storage system, patents (?), SVN skeleton
May 27 17:28:30 <beyonddc> Coding standard… I'll just go online and find a reasonable coding standard and we'll follow it, okay?
May 27 17:28:50 <clsk> I think we should all pop up here whenever possible so we can have live discussions among eachother.
May 27 17:28:52 <J_K9> beyonddc - yes. please add that to the wiki as well!
May 27 17:29:03 <Cupu> beyonddc: OH yes .. that's a big point .. yes .. find something resonable .. we'll augment it with the doxygen stuff (that we'll all learn) and that's that
May 27 17:29:13 <J_K9> yes, and if we come up with anything interesting/important then just fire off and email to the mailing list
May 27 17:29:18 <beyonddc> k
May 27 17:29:38 <clsk> I think we should go with MY coding standard :D
May 27 17:29:40 <clsk> just kidding ;)
May 27 17:29:41 <Cupu> :D
May 27 17:29:42 <J_K9> haha! :P
May 27 17:29:45 <beyonddc> Let's exchange instant messaging contact info on mailing list
May 27 17:30:02 <clsk> hm how about we just come here :)
May 27 17:30:03 <ananth> and if we have some doubts (for ex on how to use some lib of asio) do we have that discussion on the mailing list or do we use the Mia forum?
May 27 17:30:12 <ananth> *Mira
May 27 17:30:20 <J_K9> I think the mailing list is best
May 27 17:30:20 <Cupu> I have no clue
May 27 17:30:33 <clsk> I think mailing list is better too.
May 27 17:30:43 <ananth> ok, fine
May 27 17:30:48 <beyonddc> Your best bet will use the boost mailing list for problems with asio
May 27 17:30:50 <Cupu> But .. either way .. if it's important .. the next person will surely say what the first one thought of (mailing list) .. and it will endup there either way
May 27 17:30:56 <beyonddc> All of us should join boost maliing list anyway
May 27 17:31:03 <J_K9> by the way, I'm almost always on Gtalk when available - all of you should have my address :)
May 27 17:31:10 <clsk> boost has a channel on this network too.
May 27 17:31:15 <beyonddc> i c
May 27 17:31:19 <clsk> you can get good help there
May 27 17:31:24 <J_K9> great
May 27 17:31:28 <beyonddc> I'll try to drop by on this channel as much as possible
May 27 17:31:30 <ananth> thats good
May 27 17:31:39 <clsk> only other IM system I use is msn
May 27 17:31:43 <Cupu> Again .. with my apologies .. I really have to head out .. I havee to say my goodbye's though
May 27 17:31:55 <beyonddc> Bye Stefen
May 27 17:31:56 <clsk> bye Stefan.
May 27 17:32:02 <ananth> me too, have to go guys, bye all
May 27 17:32:03 <J_K9> bye, and thanks a lot for attending! :)
May 27 17:32:10 <Cupu> It was really great, and I mean GREAT speaking to you all … can't wait to make this at least a weekly/montly habbit …
May 27 17:32:11 <beyonddc> I've AIM, MSN and ICQ
May 27 17:32:18 <ananth> great meeting you all
May 27 17:32:24 <beyonddc> By Ananth
May 27 17:32:27 <beyonddc> Bye*
May 27 17:32:28 <clsk> bye ananth
May 27 17:32:29 <Cupu> Have continuing fun, and a great day/night … Cheers
May 27 17:32:30 <beyonddc> Stupid keyboard!
May 27 17:32:31 <beyonddc> 
May 27 17:32:33 <Cupu> AH!
May 27 17:32:34 <J_K9> yes, this was very useful - another one next week too hopefully!
May 27 17:32:35 <Cupu> AHA!
May 27 17:32:38 <Cupu> damn keyboard :))
May 27 17:32:40 <Cupu> good bye
May 27 17:32:41 <J_K9> haha!
May 27 17:32:47 <J_K9> goodbye Stefan and Ananth :)
May 27 17:32:54 * ananth has quit (“Leaving”)
May 27 17:33:33 <clsk> J_K9 are you going to put everybody's main roles in the wiki?
May 27 17:33:50 <J_K9> I could do that, unless you would rather fill them in yourselves?
May 27 17:33:56 <beyonddc> um…anyone will summarize today's meeting and send it ou on mailing list or something?
May 27 17:33:59 <clsk> you can do it :D
May 27 17:34:03 <J_K9> hehe ok
May 27 17:34:19 <J_K9> beyonddc, I will if I have the time
May 27 17:34:24 <beyonddc> k
May 27 17:34:28 <J_K9> I will do my best to send out a summary within a few hours :)
May 27 17:34:35 <clsk> cool
May 27 17:34:35 <beyonddc> that's fine, no rush
May 27 17:34:46 <beyonddc> I need to eat some breakfast now
May 27 17:34:49 <beyonddc> so… take care people
May 27 17:34:49 <J_K9> hehe, ok
May 27 17:34:49 <clsk> same here
May 27 17:34:56 <J_K9> great speaking to you all!
May 27 17:34:59 <clsk> I'll probably upload some code before wednesday
May 27 17:35:02 <beyonddc> yup
May 27 17:35:06 <J_K9> great
May 27 17:35:08 <clsk> yuss
May 27 17:35:09 <clsk> same
May 27 17:35:14 <clsk> bye now
May 27 17:35:18 <J_K9> goodbye :)
Discussion