Mira Groupware

Attendees: ananthbv, beyonddc, clsk, Cupu, J_K9, Jef1

Note: All timestamps in UTC+1 (British Summer Time).

---

Jun 03 16:04:19 * Now talking on #mira

Jun 03 16:04:19 * #mira :[freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg

Jun 03 16:04:19 <Cupu> hmm .. it should be like 15:00 there

Jun 03 16:04:25 <clsk> there he is ;)

Jun 03 16:04:27 <beyonddc> Here's Max

Jun 03 16:04:29 <J_K9> hi all - sorry i'm late :)

Jun 03 16:04:30 <Cupu> heh .. we spoke too soon :)

Jun 03 16:04:33 <ananth> our PM is here!

Jun 03 16:04:38 <J_K9> hehe

Jun 03 16:04:48 <J_K9> good to see Jeff here too :)

Jun 03 16:05:09 <Jef1> It's hard, but apparently for a good cause…

Jun 03 16:05:20 <J_K9> indeed!

Jun 03 16:05:51 <Cupu> Anyone else expected?

Jun 03 16:06:19 <J_K9> no - Daryl cannot make it and I don't think Bart is coming, although I have emailed him (I don't think he's read it yet)

Jun 03 16:06:29 <J_K9> shall we begin?

Jun 03 16:06:45 <Cupu> yup

Jun 03 16:07:08 <J_K9> ok

Jun 03 16:07:35 <J_K9> let's start by discussing the requirements of a certain subsystem - unless Jeff would like to talk about the data flow diagrams first?

Jun 03 16:07:55 <clsk> hm. Do we really need data flow diagrams?

Jun 03 16:08:12 <Jef1> hey, I'm attending my first meeting, don't want to barge in too much…:$

Jun 03 16:08:27 <Jef1> No you don't

Jun 03 16:09:00 <clsk> What I'm trying to say is… What benefits will it bring?

Jun 03 16:09:11 <clsk> s/say/ask.

Jun 03 16:09:58 <Jef1> 1) documentation

Jun 03 16:09:59 <Jef1> 2) Uniformity

Jun 03 16:09:59 <Jef1> 3) AGreeing on same ideas

Jun 03 16:10:15 <J_K9> As well as allowing us to better visualise the interaction between the different layers

Jun 03 16:10:49 <Jef1> 5) Make sure we don't forget anything

Jun 03 16:11:03 <clsk> hm

Jun 03 16:11:25 <J_K9> So how comprehensive would the data flow diagramming need to be, and where would we begin? How would we all work on the diagrams as a team?

Jun 03 16:11:31 <Jef1> For all to read (later): http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=240

Jun 03 16:12:35 <beyonddc> ah, that looks like a good read.

Jun 03 16:13:04 <beyonddc> Yesterday we had a pretty good discussion.

Jun 03 16:13:18 <Jef1> To really work as a team seems rather difficult to me, during the first phase. But what's always possible is that we have sub-teams timzeone-wise

Jun 03 16:13:28 <beyonddc> We talked about the overall concept of what we want.

Jun 03 16:13:45 <Cupu> While I as a person don't have any love or hate for such diagrams .. it will help devs a lot .. with a predilaction for newcomers (?!)

Jun 03 16:14:07 <J_K9> True

Jun 03 16:14:41 <beyonddc> Well, we don't need to dig deep down into documentation that much. Just a couple of data flow diagram, component diagram that illustrate each layer should be good enough.

Jun 03 16:14:46 <J_K9> Perhaps a member of each sub-team (i.e. in charge of a subsystem) could make the data flow diagrams centred around its functionality?

Jun 03 16:14:46 <clsk> I've always “disliked” data flow diagrams. Since my first programming class in 6th grade.

Jun 03 16:15:28 <beyonddc> ummm….

Jun 03 16:15:56 <J_K9> They shouldn't take too long to make in any case, and they should prove useful in the future in order to remind ourselves and teach others how the subsystems interact and how data is transferred in our platform

Jun 03 16:16:22 <J_K9> using “transferred” fairly universally, of course

Jun 03 16:16:31 <Jef1> @clsk: those dagrams, could they have been Nassi-shneidermanns, or other programming diagrams? They've got very little to do with Data flow Diagrams…

Jun 03 16:16:31 <Jef1> I downloaded Visual Paradigm Community Edition (free), from http://www.visual-paradigm.com/product/vpuml/vpumldownload.jsp?edition=ce&product=vpuml

Jun 03 16:16:43 <beyonddc> Max, we need to identify each subsystem first.

Jun 03 16:16:50 <Jef1> correct

Jun 03 16:17:01 <J_K9> ok

Jun 03 16:17:11 <J_K9> there are:

Jun 03 16:17:17 <J_K9> networking layer

Jun 03 16:17:31 <J_K9> SVN (version control) layer

Jun 03 16:17:34 <J_K9> database layer

Jun 03 16:17:50 <J_K9> above those, Utilities API and above that Utilities

Jun 03 16:18:12 <J_K9> and..

Jun 03 16:18:28 <beyonddc> umm…

Jun 03 16:18:32 <clsk> I've got something to say about version control.

Jun 03 16:18:38 <Cupu> can we call the svn layer .. simply version control layer (even though svn might be our back-bone at first) ?

Jun 03 16:18:54 * clsk agrees

Jun 03 16:18:58 <J_K9> yes, Cupu, I agree - particularly at this stage

Jun 03 16:19:04 <ananth> one question, do we really require the netwroking layer? because all the networking functionalites are encompassed by the libs we use like asio/boost?

Jun 03 16:19:31 <Cupu> ananth: I think we should .. because the idea was that we'll have an extra (mira-personal) wrapper on top of that

Jun 03 16:19:42 <Cupu> so we can switch libaries with *relative* ease

Jun 03 16:19:47 <clsk> Last night I came across a google talk video of a presentation on version control systems where I pretty much realized that SVN isn't probably the best we can get.

Jun 03 16:19:52 <J_K9> indeed - we wanted to abstract it as much as possible

Jun 03 16:19:53 <Cupu> (there's ALOT of code to be written :)

Jun 03 16:20:06 <beyonddc> mira is sort of like an infrastructure. We wrap around the asio and all utility will just plug-n-play.

Jun 03 16:20:11 <J_K9> clsk - could you please expand on that?

Jun 03 16:20:22 <ananth> ok, got it

Jun 03 16:20:51 <clsk> ananth: We do. Even though the OS APIs are wrapped by asio and other networking libraries, there are things that other developers shouldn't even be concerned about.

Jun 03 16:21:08 <clsk> J_K9: Give me a second so I can find the link and then expand on it.

Jun 03 16:21:12 <J_K9> ok

Jun 03 16:21:30 <clsk> Video

Jun 03 16:21:46 <clsk> that's the link. The talk is rather long so…

Jun 03 16:21:48 <beyonddc> Alan, I will watch that later.

Jun 03 16:21:53 <J_K9> as will I

Jun 03 16:21:55 <Cupu> I think we could call it the version control layer .. and expand this on the mailing list … just so we don't loose focus now :)

Jun 03 16:22:05 <J_K9> yes, let's continue to discuss the requirements

Jun 03 16:22:11 <beyonddc> Max, I'll volunteer to draw out the subsystem diagram

Jun 03 16:22:34 <clsk> anyways he talks about how CVS and SVN are bad at branching and merging which is something I think we might need in the future.

Jun 03 16:22:36 <ananth> thanks Alan, will watch that later

Jun 03 16:22:39 <J_K9> thank you, David

Jun 03 16:23:02 <beyonddc> Jeff, are you familiar with our concept on how we want Mira to be?

Jun 03 16:23:07 <clsk> He talks about git though which is not something that we will be able to use, first because there's no native version in windows and secondly because it uses a distributed system. I think we might prefer the centralized server.

Jun 03 16:23:25 <clsk> ok you guys watch it and then we can discuss the topic later.

Jun 03 16:24:07 <Jef1> You were talking Design or Implementation… so I just waited a little

Jun 03 16:24:08 <Jef1> I got a pretty good general idea I think, but don't hesitate to explain me again!

Jun 03 16:24:52 <beyonddc> Jeff, basically we identified different layers in Mira (networking, version control, database and etc). Each layer will provide its own API so the utility/plug-in developer can program on.

Jun 03 16:25:08 <beyonddc> We want to create an infrastructre like platform.

Jun 03 16:25:14 <Jef1> Like an Operating System

Jun 03 16:25:22 <beyonddc> sort-of, but in application level

Jun 03 16:25:34 <clsk> yes, pretty much like an OS works.

Jun 03 16:25:37 <beyonddc> We will wrap everything.

Jun 03 16:25:42 <J_K9> yes

Jun 03 16:26:07 <beyonddc> So the key of mira from my point of view is a well defined interface

Jun 03 16:26:11 <J_K9> And I assume we will need to have a “core layer”, a controller of sorts to link all of these layers together?

Jun 03 16:26:29 <Cupu> J_K9: That will be below the api

Jun 03 16:26:35 <beyonddc> Not exactly… it doesn't need to link together.

Jun 03 16:26:40 <Jef1> What is the degree of cooperation between Utilities?

Jun 03 16:26:53 <J_K9> There needs to be interaction between them

Jun 03 16:27:05 <J_K9> This is something we will need to discuss when defining the requirements of the Utility layer

Jun 03 16:27:13 <clsk> What I was thinking was implementing a messaging system within the core for utilities to communicate.

Jun 03 16:27:27 <beyonddc> We can provide an inter-process communication layer also

Jun 03 16:27:27 <Cupu> J_K9: Well while we did lay out all those layers .. you will only be able to interact at either the client or server level (both actually) .. so those things are going to be pretty much glued already

Jun 03 16:27:28 <Jef1> To give an example: I want to store an IM-discussion in a database, with a link to a customer record

Jun 03 16:27:40 <clsk> The same for utilities to communicate between the client and the server.

Jun 03 16:27:48 <J_K9> clsk - That would not be a bad idea. How would one Utility link to another?

Jun 03 16:28:05 <J_K9> Cupu - ah, ok. thank you.

Jun 03 16:28:27 <clsk> hm I don't think we'll need inter-process communication since it's all going to be inside the same process. And for client/server communication we can just use simple text messaging across the network.

Jun 03 16:28:45 <beyonddc> In ACE, there's inter-process queue that one thread can talk with another thread. I'm pretty sure boost will have something similar.

Jun 03 16:28:49 <J_K9> Or, to give another example, a Calendar item linking to a Note in the same Workplace

Jun 03 16:29:06 <clsk> J_K9: They'd use they'd use the defined API to communicate with eachother.

Jun 03 16:29:14 <Jef1> … linked to a customer again

Jun 03 16:29:15 <beyonddc> But I don't think we need to worry about how those stuffs work yet.

Jun 03 16:29:28 <Cupu> clsk: Exactly .. basically each utility (plug-in/whatever) will be able to describe it's functionality .. so that other devs now how to query it .. I don't think (perhaps I'm worng) this is a very big obstacle

Jun 03 16:29:44 <clsk> Not at all Cupu.

Jun 03 16:29:45 <J_K9> indeed, but there would have to be a unique identifiable name within the Utility's own code so that its presence can be recognised by other Utilities in the Workplace

Jun 03 16:29:51 <clsk> I was actually think about it last night.

Jun 03 16:30:10 <Cupu> As long as they implement a common interface and they're documented .. it's all blue skies

Jun 03 16:30:20 <Cupu> (or is that clear skies)

Jun 03 16:30:35 <Cupu> We can use something like GUID's in COM

Jun 03 16:30:37 <ananth> blue sky is a clear sky, right?

Jun 03 16:30:43 <Cupu> or XPCOM just so that no one get's uspet :)

Jun 03 16:30:48 <J_K9> Exactly. But these are things we need to think of when defining the requirements of the Utilities layer and what the interface layer below it must provide for Utility developers

Jun 03 16:30:49 <Cupu> ananth: I have no idea :D

Jun 03 16:31:36 <beyonddc> Jeff, do you've anything to add-on?

Jun 03 16:31:57 <Cupu> J_K9: Well those are decisions really at the code level, is it enaugh to say that each utility can be queried for functionality and that it should contain a globally unique identifier in the system?!

Jun 03 16:32:18 <beyonddc> I think in this meeting, let's just briefly talk about each sub-system. And identify ones that we might missed previously.

Jun 03 16:32:27 <Jef1> Just a question: if developing Groupware is that simple, then why did Lotus Notes development take (at least) 100 man-year ?

Jun 03 16:32:27 <Jef1> And did you all read the Definition study ?

Jun 03 16:32:45 <beyonddc> I read the DS.

Jun 03 16:32:46 <clsk> No one said it was simple.

Jun 03 16:33:06 <Cupu> I thought no one said it was simple .. rather we're trying to simplify the first steps just so we don't get overwhealmed to fast

Jun 03 16:33:08 <J_K9> Cupu - is that really enough? we do need to remember that there would need to be a way for a Utility to provide a “link” to an element in another Utility, if you see what I mean

Jun 03 16:33:14 <Jef1> What's good about Lotus Notes is the very high degree of integration

Jun 03 16:33:30 <Jef1> If you focus on Utilities, you'llnever achieve integration

Jun 03 16:33:54 <clsk> Just because they are separate entities doesn't mean they can't be well-integrated.

Jun 03 16:34:04 <J_K9> I agree

Jun 03 16:34:14 <clsk> Which is why we were just talking about how they will communicate with eac-other.

Jun 03 16:34:35 <clsk> Maybe I'm overlooking the problem.

Jun 03 16:34:40 <clsk> Can you be more specific?

Jun 03 16:34:41 <Cupu> J_K9: You're right .. I didn't mean to over simplify .. but using a common interface is a way to enforce such constraints

Jun 03 16:34:51 <Jef1> It's not “communicate” it's deeper than that

Jun 03 16:35:14 <beyonddc> Jeff, can you explain a little more?

Jun 03 16:35:18 <Cupu> No doubt we're up agains a very complex design, but do we want to have it done tonight?

Jun 03 16:35:25 <J_K9> Cupu - yes, I agree. But we can discuss this in more detail at another time :)

Jun 03 16:36:08 <Jef1> Okay, I suggest that Max an I will continue to look at the analysis and requirements

Jun 03 16:36:36 <clsk> hm

Jun 03 16:36:49 <beyonddc> I don't mind

Jun 03 16:36:49 <clsk> Jef1: Could you expand a little more on what you just said?

Jun 03 16:36:52 <Jef1> Downside of this: while you continue, you may have to adapt your ideas to the progressing requirements …

Jun 03 16:37:10 <J_K9> I think we've all got a pretty equal idea of what we want in Mira though

Jun 03 16:37:13 <Cupu> Jef1: You're right about that … but I'm not sure how we can avoid it (if possible)

Jun 03 16:37:48 <Jef1> I know, just like building a house: you've got a pretty good idea, now let's lay some bricks!

Jun 03 16:38:02 <clsk> well… lets

Jun 03 16:38:03 <Cupu> :)

Jun 03 16:38:05 <J_K9> :)

Jun 03 16:38:05 <clsk> that's why we're here

Jun 03 16:38:39 <Jef1> But you don't know: how many people are going to live in it, what's South, where the hell we can get water in the Sahara, etc

Jun 03 16:38:41 <J_K9> Alan, we wouldn't be doing it by ourselves. we would merely be doing the first draft which we obviously go through substantial peer review by the whole team

Jun 03 16:39:01 <J_K9> *we=would

Jun 03 16:39:14 <Jef1> Indeed.

Jun 03 16:39:25 <beyonddc> I don't mind letting Max and Jeff to do the analysis and requirements.

Jun 03 16:39:32 <Cupu> ditto

Jun 03 16:39:38 <beyonddc> We'll submit our comments if we think the requirement sucks.

Jun 03 16:39:42 <beyonddc>

Jun 03 16:39:43 <J_K9> ;)

Jun 03 16:39:45 <Cupu> :)

Jun 03 16:39:48 <clsk> I thought we were here to discuss the design and analysis of mira.

Jun 03 16:39:56 <clsk> well

Jun 03 16:40:00 <beyonddc> Yea..

Jun 03 16:40:03 <clsk> not the whole application, but the core of it.

Jun 03 16:40:07 <beyonddc> I know what you mean Alan.

Jun 03 16:40:30 <J_K9> true, but I think we need to document the requirements of each subsystem first - shall we discuss each individually now?

Jun 03 16:40:42 <beyonddc> before that

Jun 03 16:40:51 <beyonddc> we need to ensure we've all the sub system right

Jun 03 16:40:54 <beyonddc> …

Jun 03 16:40:57 <clsk> right

Jun 03 16:41:03 <J_K9> ok

Jun 03 16:41:13 <beyonddc> i don't even think we've all subsystem identified yet. We know the general ones, but I think there should be more.

Jun 03 16:41:22 <clsk> so what sybsystems do we have?

Jun 03 16:41:28 <beyonddc> As always…

Jun 03 16:41:38 <beyonddc> version control, networking, database

Jun 03 16:41:51 <J_K9> anything else on that level?

Jun 03 16:41:58 <clsk> Here are some: Directory, Network, version control.

Jun 03 16:42:01 <clsk> hm database?

Jun 03 16:42:12 <Jef1> translation services?

Jun 03 16:42:19 <clsk> I think database should be something done by the utility.

Jun 03 16:42:19 <J_K9> database is required for Utility data storage (for non-version controlled storage)

Jun 03 16:42:22 <Cupu> Jef1: definately

Jun 03 16:42:32 <clsk> translation services?

Jun 03 16:42:50 <J_K9> would translation be on the same layer? by translation do you mean localisation or translation in a Utility, for example?

Jun 03 16:42:57 <Jef1> yes

Jun 03 16:43:14 <Jef1> translation in a final Utility

Jun 03 16:43:49 <J_K9> ah, ok - in that case it should not count as a subsystem, IMHO, as it will plug into Mira using the Utility interface layer which sits above the currently identified ones

Jun 03 16:44:07 <clsk> Here's some decent documentation I found on localization on C++ by bjarne (the guy that designed C++)

Jun 03 16:44:07 <clsk> http://www.research.att.com/~bs/3rd_loc.pdf

Jun 03 16:44:31 <clsk> It's part of his book the c++ programming language.

Jun 03 16:44:36 <beyonddc> Thanks Alan, I'll read it later.

Jun 03 16:44:37 <J_K9> thanks clsk - I'll look over that later

Jun 03 16:44:52 <Cupu> well probably translation will be part of the api

Jun 03 16:44:59 <clsk> so we might want to include localization as part of the core.

Jun 03 16:45:03 <Cupu> Wow .. that soudned wrong

Jun 03 16:45:06 <clsk> but maybe for a later version.

Jun 03 16:45:07 <Cupu> yes .. what alan said

Jun 03 16:45:16 <J_K9> I agree

Jun 03 16:45:17 <Jef1> I'd call it subsystem. And archiving? not only database, but related to versioning?

Jun 03 16:45:19 <Cupu> I think we should begin with it from the start

Jun 03 16:45:28 <beyonddc> directory, database, networking, version control

Jun 03 16:45:31 <clsk> hm about version control

Jun 03 16:45:39 <J_K9> what is the directory layer for?

Jun 03 16:45:39 <clsk> we should probably have a Storate Syb-system

Jun 03 16:45:43 <Cupu> basically a utility should be queired if it support ssystem wide translation changes .. other wise .. it will revert to some default

Jun 03 16:45:46 <clsk> subsystem

Jun 03 16:46:03 <J_K9> clsk - and below the Storage subsystem have the database and version control layers?

Jun 03 16:46:13 <Cupu> clsk: I can't remember weather averyone agreed last time on this, will we be flasible as to support any kind of storage backend?

Jun 03 16:46:16 <clsk> and then have version control, simple files and database on top of that.

Jun 03 16:46:19 <Cupu> (i'd incline to say yes)

Jun 03 16:46:29 <clsk> right

Jun 03 16:46:53 <Cupu> *flexible (shoot the keyboard)

Jun 03 16:47:07 <ananth> clsk: what is the directory subsystem?

Jun 03 16:47:15 <Jef1> would that mean you can have versions of databases, or databases with versions in it?

Jun 03 16:47:16 <clsk> So we have: Directory, Network, Storage.

Jun 03 16:47:29 <J_K9> what is Directory?

Jun 03 16:47:35 <clsk> ananth: Used for Authentication and querying of Workgroups, Users and permissions.

Jun 03 16:47:44 <ananth> like LDAP?

Jun 03 16:47:50 <clsk> LDAP will be one of them, yes.

Jun 03 16:47:51 <Jef1> User Directory, Name&Address Book

Jun 03 16:47:58 <ananth> ok

Jun 03 16:47:58 <J_K9> ah, ok. an abstracted authentication and permissions layer then

Jun 03 16:48:19 <clsk> I wrote some code to illustrate my ideas.

Jun 03 16:48:19 <J_K9> Jeff - what do you mean by an archiving layer/service?

Jun 03 16:48:51 <clsk> It's pretty easy to create a flexible system for this with wich the user can choose at start-time which one to use (LDAP, Database or other system).

Jun 03 16:49:05 <J_K9> we will need to bear in mind that the directory layer should support standard simple auth to begin with and later LDAP, etc

Jun 03 16:49:08 <Jef1> I like my mail in a database, but not all of it; last year's may be moved to an archive

Jun 03 16:49:23 <J_K9> I think that could be handled by Mira Client

Jun 03 16:49:42 <ananth> is mail client also part of mira?

Jun 03 16:49:49 <J_K9> by the way, I think *all* message data should be removed from the server as soon as it has been successfully sent to the Client in order to prevent snooping

Jun 03 16:50:08 <clsk> right

Jun 03 16:50:15 <J_K9> an email client may be added to a future version, but inter-user messaging system should be implemented fairly near the beginning

Jun 03 16:50:18 <Cupu> hmmm .. what if you change computers?!

Jun 03 16:50:24 <J_K9> allow the user to back up and restore

Jun 03 16:50:30 <J_K9> :)

Jun 03 16:50:54 <Cupu> cool :) .. we should definately tell them then .. because they'll be angyr the first time :D

Jun 03 16:50:55 <J_K9> if not, there's a certain security risk involved. plus, we don't want messages with attachments and such overloading the Mira Server

Jun 03 16:50:59 <Cupu> but I guess there's no way around it

Jun 03 16:51:02 <J_K9> haha! yes, Cupu, I agree ;)

Jun 03 16:51:04 <beyonddc> inter-user messaging? what do you mean? Are you just talking about instant messaging?

Jun 03 16:51:05 <clsk> So before we get too offtopic. What layers do we have?

Jun 03 16:51:07 <J_K9> not as far as I know

Jun 03 16:51:34 <clsk> Directory, Networe, Storage… What else?

Jun 03 16:51:37 <J_K9> beyonddc - no. it allows users on the same Mira Server to send each other messages. please see the mock-ups (that should give you a better idea of it) :)

Jun 03 16:51:42 <clsk> Localization (for a later version)

Jun 03 16:51:45 <J_K9> yes

Jun 03 16:52:03 <J_K9> Utilities interface layer, for pluggable modules on top

Jun 03 16:52:13 <clsk> right

Jun 03 16:52:18 <J_K9> is there anything else?

Jun 03 16:52:32 <beyonddc> utility interface is what the directory, network and storage provides.

Jun 03 16:53:08 <J_K9> should we not abstract the Utilities API layer on top of the others?

Jun 03 16:53:22 <clsk> well the utility API will abstract all the subsystems.

Jun 03 16:53:26 <J_K9> that will allow us to specify exactly what features and functionality Utility developers may use

Jun 03 16:53:32 <clsk> right

Jun 03 16:53:34 <beyonddc> umm…

Jun 03 16:53:47 <Cupu> I think utility is just a concept

Jun 03 16:53:49 <J_K9> because we may not wanting Utilities, for example, to be able to access the messaging functionality in the networking layer

Jun 03 16:53:52 <Cupu> I would scratch that entierely

Jun 03 16:53:53 <J_K9> *want

Jun 03 16:53:59 <Cupu> Every layer will provide an api .. period

Jun 03 16:54:11 <beyonddc> that's what I am thinking, Stefen

Jun 03 16:54:12 <Cupu> In my world that is

Jun 03 16:54:25 <J_K9> but how will we then control which functionality a Utility has access to? unless we don't want to do that, of course

Jun 03 16:54:32 <J_K9> I'm just trying to think about it from a security POB

Jun 03 16:54:34 <J_K9> *POV

Jun 03 16:54:49 <beyonddc> the security is done inside the layer.

Jun 03 16:54:54 <beyonddc> inside the layer implementation

Jun 03 16:54:57 <J_K9> I know

Jun 03 16:55:01 <clsk> I think we should have the Utility API be a layer for all the subsystems.

Jun 03 16:55:04 <Cupu> well different things will have different interfaces with different access levels .. .. the Utility word was just nagging me

Jun 03 16:55:16 <clsk> This means that the utility developers don't need to know about subsystems.

Jun 03 16:55:26 <J_K9> but what if an external Utility started using a certain subsystem it shouldn't be?

Jun 03 16:55:27 <J_K9> indeed

Jun 03 16:55:29 <Jef1> Security is usually the top-layer

Jun 03 16:55:30 <beyonddc> Alan, I don't have a heart-burn for an utility api. So go ahead

Jun 03 16:56:01 <Jef1> Or an in-between layer

Jun 03 16:56:04 <J_K9> oh, by the way, what about the messaging layer? surely that will need to be separated from the storage and networking layers on the Client's end to manage stored messages and such separately?

Jun 03 16:56:05 <clsk> It's just my opinion. If you guys think otherwise then we should discuss the advantages and disadvantages of each.

Jun 03 16:56:17 <clsk> right.

Jun 03 16:56:32 <clsk> I could expand on that if you guys want me too.

Jun 03 16:56:37 <Cupu> And it can certanly do that .. I'm just scared that we might get to hung up on words

Jun 03 16:56:53 <J_K9> ok

Jun 03 16:57:45 <Cupu> alan, please go ahead

Jun 03 16:57:54 <clsk> ok Utilities will be able to communicate with other utilities within the same application AND across the network.

Jun 03 16:58:04 <Cupu> right …

Jun 03 16:58:29 <clsk> For communicating inside the application each application will have to register to the messaging system. (that will be a requirement for plugins)

Jun 03 16:58:58 <beyonddc> I think we digged into a little too deep.

Jun 03 16:59:12 <clsk> right. that's why I didn't want to go too in-depth.

Jun 03 16:59:27 <clsk> but I pretty much have a good idea of how it should work. I've done something similar in the past.

Jun 03 16:59:49 <beyonddc> Why we need to enforce them to use our own inter-process messaging system?

Jun 03 16:59:56 <beyonddc> They can do it easily on their own.

Jun 03 17:00:00 <clsk> All network messages will go through the messaging system and it will decide who to send these messages to.

Jun 03 17:00:06 <J_K9> Alan, would you mind explaining that in greater depth on the mailing list? It's probably something we should discuss on there :)

Jun 03 17:00:16 <clsk> beyonddc: It's not inter-process communication.

Jun 03 17:00:29 <ananth> Alan, is it something like a publish/subscribe mechanism?

Jun 03 17:00:30 <clsk> sure.

Jun 03 17:00:36 <Cupu> it's INTRAprocess comunication I think :)

Jun 03 17:01:18 <ananth> intra-process??

Jun 03 17:01:18 <clsk> Although inter-process communication is also included. Communication within the same process will be integrated too.

Jun 03 17:01:27 <J_K9> that's the thing though, it's not IPC - it is just a Utility calling another Utility within the same application/process. at least AFAIK

Jun 03 17:01:33 <Cupu> I made that up .. sorry should joke less

Jun 03 17:01:36 <J_K9> :P

Jun 03 17:01:41 <ananth> :)

Jun 03 17:01:46 <clsk> J_K9: Correct.

Jun 03 17:01:58 <Jef1> How can you make sure Mira isn't going to be just another Instant Messenger ?

Jun 03 17:01:58 <Jef1> How are you going to do message synchronization?

Jun 03 17:02:09 <ananth> anyway, would be looking forward to Alan's mail

Jun 03 17:02:12 <J_K9> indeed

Jun 03 17:02:20 <Cupu> Jef1: I think that's too deep for the disscution

Jun 03 17:02:25 <clsk> Jef1: I don't understand your question.

Jun 03 17:02:30 <Cupu> we could line up papers and documents books and so on

Jun 03 17:02:41 <Cupu> But I don't think now is the time

Jun 03 17:02:51 <Jef1> Ok, I'll wait

Jun 03 17:03:06 <Cupu> we can work on it expand ideas … have meetings like this .. define .. analyse .. apply

Jun 03 17:03:27 <Cupu> We're pretty early along the way .. I don't know how we'll synchornize .. I just know we'll have to

Jun 03 17:03:51 <clsk> Jef1: What do you mean by syncronizing messages?

Jun 03 17:04:03 <beyonddc> ensure they're in orders

Jun 03 17:04:07 <J_K9> I'm also unsure of what you mean by that :)

Jun 03 17:04:16 <clsk> I don't think that will be something hard to do.

Jun 03 17:04:17 <Cupu> I'd have no problem if yahoo messenger would be so extensible as we'd like mira to be .. chances are if it were .. it would have already be a groupware platform

Jun 03 17:04:38 <Jef1> Two ways: 1) you just send, and ath the other end there's an asynchronous process that displays the messages 2) you send and wait for a response

Jun 03 17:04:42 <clsk> Jef1: Mira is NOT intended to be a messaging system.

Jun 03 17:04:49 <J_K9> indeed

Jun 03 17:04:55 <Jef1> I know :)

Jun 03 17:05:09 <Cupu> Jef1: that's really down to the code level …

Jun 03 17:05:15 <Jef1> But if you focus on messaging, what else will it be?

Jun 03 17:05:24 <Cupu> No wait

Jun 03 17:05:33 <Jef1> groupware is a LOT more (maybe I'm too hung up on the word roupware…)

Jun 03 17:05:46 <Cupu> wait wait .. how did we get back to IM?

Jun 03 17:05:47 <clsk> the messaging we're talking about is messaging inside the application itself and not Instant Messages.

Jun 03 17:05:57 <clsk> Of course it is.

Jun 03 17:05:58 <Cupu> We were talking about utilities comunicating with each other (internally)

Jun 03 17:06:04 <J_K9> I think we're confusing ourselves with the word 'messaging'. One is referring to messages between Users (email-like messages), the other is messages sent by Utilities to the app itself for interpretation

Jun 03 17:06:32 <Jef1> IM is an example of messaging

Jun 03 17:06:36 <beyonddc> I wasn't even thinking about IM when we talking about messaging.

Jun 03 17:06:53 <beyonddc> I was thinking messagining as a communication between process to process or inter-process.

Jun 03 17:07:03 <clsk> For some reason Jef1 is.

Jun 03 17:07:07 <Cupu> yes .. there was a misunderstanding here

Jun 03 17:07:08 <Jef1> Can you give an example of such messaging?

Jun 03 17:07:10 <J_K9> but IM uses the networking layer alone (plus the directory layer to find out who receives the messages) - it does not count as a separate layer

Jun 03 17:07:36 <J_K9> Jeff - such messaging is a Calendar item linking to a note in the Notes Utility, I believe

Jun 03 17:07:43 <clsk> Right

Jun 03 17:07:46 <J_K9> whereby one Utility links to another

Jun 03 17:07:53 <Cupu> Let's not talk about instant messaging at all today …

Jun 03 17:07:54 <J_K9> and can communicate with it

Jun 03 17:08:07 <beyonddc> It depends on your definition of “message”. A message is basically anything you can serialize and send through the netowrk.

Jun 03 17:08:17 <clsk> the Notes Calendar utility will have to communicate with the Notes utility so they can be well-integrated (like you said, the key is integration between features)

Jun 03 17:08:33 <Cupu> rephrasing .. let's not touch the subject of persons communicating in real time with each -other at all today .. so there's no confusion

Jun 03 17:08:40 <Jef1> The Calendar example: why does it have to be sent through the network?

Jun 03 17:08:46 <Cupu> it doesn't

Jun 03 17:08:55 <Cupu> it comunicates with the note in the same address space .. same process

Jun 03 17:08:59 <J_K9> oh, by the way, about this - I don't think we should restrict that to Utilities alone. the Messaging system (i.e. email-like messages) might also need to interface with Utilities in a Workplace, e.g. I could 'send' a received message to the Notes Utility in one of my Workplaces as a note

Jun 03 17:09:08 <J_K9> but that's probably too in-depth in any case :)

Jun 03 17:09:09 <clsk> Jef1: It doesn't. We're talking about messages sent within the application.

Jun 03 17:09:11 <Cupu> it says .. look Notes .. I'mCalendar and just got activated … I'm here two if you need me or I need you

Jun 03 17:09:16 <clsk> It doesn't have to be sent through the network to be a message.

Jun 03 17:09:22 <J_K9> exactly

Jun 03 17:09:32 <Cupu> *too

Jun 03 17:09:48 <J_K9> UNLESS it is communicating data to it, as in the received message→note exactly – then that would be local and network-related

Jun 03 17:09:51 <clsk> Good example there Cupu.

Jun 03 17:09:58 <J_K9> *exactly=example

Jun 03 17:10:08 <Cupu> keyboard?

Jun 03 17:10:13 <J_K9> yes ;p

Jun 03 17:10:18 <clsk> Do you understand what we're talking about now Jef1?

Jun 03 17:11:00 <Jef1> Ehm, yes, think so, but …

Jun 03 17:11:42 <J_K9> Data is only sent through the network if there is a change in the data of the Workplace, not if an element in a Utility links to another (which counts as data, which has already been distributed to the other clients so does not need to be re-sent because there has not been a change).

Jun 03 17:11:43 <Jef1> My non-districuted mind has some difficulties…

Jun 03 17:11:48 <clsk> basically what we're trying to say is that these are not messages that the users see or send themselves. These might be messages (and in most cases will be) messages sent within the same application.

Jun 03 17:11:58 <Jef1> *non-distributed

Jun 03 17:12:23 <clsk> I agree too many people trying to explain the same concept.

Jun 03 17:12:47 <Cupu> There's one thing to note .. Utilities DO NOT need to talk to eachother

Jun 03 17:12:50 <clsk> hm What don't you understand as of right now about the messaging system that is part of the core of mira?

Jun 03 17:12:57 <clsk> Cupu: Yes, they do.

Jun 03 17:13:00 <Cupu> but just in case .. one of them provides important data for someother one .. they should

Jun 03 17:13:03 <Cupu> *they could I mean

Jun 03 17:13:31 <clsk> which is what we're discussing.

Jun 03 17:13:37 <J_K9> Cupu - there does need to be the capability to do so. it's up to the Utility developer whether their Utility can receive data from other plugins though (e.g. the Notes Utility receiving data from the Message Center)

Jun 03 17:13:43 <Jef1> No, I mean with the messages flowing through the system… or not: where are they different from database records that get copied if need be?

Jun 03 17:13:49 <Cupu> well yes .. I'm glad we're all saying the sam things :)

Jun 03 17:13:52 <Cupu> *same

Jun 03 17:13:57 <J_K9> :)

Jun 03 17:14:00 <Jef1> Is it the management or ownership of the data?

Jun 03 17:14:20 <Jef1> You're all way deeper in this, that's for sure!

Jun 03 17:14:25 <ananth> Alan, can you just give a hint on how 2 utilities would communicate with each other?

Jun 03 17:14:31 <clsk> Jef1: These are not necessarily things recorded in a database.

Jun 03 17:14:32 <J_K9> Jeff, would you mind giving an example of what you're talking about?

Jun 03 17:14:52 <clsk> ananth: We just did. Did you read the Calendar↔Notes example?

Jun 03 17:14:57 <Cupu> Jef1: It's just another concept .. it doesn't HAVE to be unique .. or the only one that does it

Jun 03 17:15:03 <ananth> i mean what exactly would you use? like IPCs, etc?

Jun 03 17:15:25 <clsk> no. It's nothing but a Class inside the application itself.

Jun 03 17:15:29 <J_K9> that's design, which we can leave till the next stage in the lifecycle :)

Jun 03 17:15:32 <Cupu> clsk: exactly!

Jun 03 17:15:35 <clsk> give me a second and I'll provide a link to something similar I made.

Jun 03 17:15:55 <ananth> Alan: that would be great, thanks

Jun 03 17:16:39 * beyondd1 (n=David@c-66-30-134-52.hsd1.ma.comcast.net) has joined #mira

Jun 03 17:16:48 <Cupu> hi David1

Jun 03 17:16:55 <J_K9> hello again, David :)

Jun 03 17:16:57 <ananth> David, is that ur alter ego?

Jun 03 17:17:00 <J_K9> lol

Jun 03 17:17:01 <Cupu> :)

Jun 03 17:17:06 <beyondd1> I didn't know I got disconnected till….. a webpage didn't load.

Jun 03 17:17:07 <clsk> Do know that this is simpler that what ours would be.

Jun 03 17:17:09 <clsk> http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enetwork/eChan/include/MsgMonitor.h?rev=HEAD&content-type=text/vnd.viewcvs-markup

Jun 03 17:17:18 <clsk> http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enetwork/eChan/src/MsgMonitor.cpp?rev=HEAD&content-type=text/vnd.viewcvs-markup

Jun 03 17:17:24 <clsk> header and source

Jun 03 17:17:47 <beyondd1> I asked a question earlier, but I think…it was sent while I was disconnted.

Jun 03 17:17:51 <Cupu> clsk: right .. we'll certanly use some observer → subscriber model there …

Jun 03 17:17:53 <ananth> thanks a lot, i was just curious about the mechanisms used

Jun 03 17:18:02 <beyondd1> I asked about what's the different between the networking and messaging.

Jun 03 17:18:10 <beyondd1> networking and messaging layer

Jun 03 17:18:15 <Cupu> And there are a lot of ways to do it .. just as shown by your code;

Jun 03 17:18:25 <clsk> beyondd1: messages are not necessarily sent through the network.

Jun 03 17:18:27 <J_K9> messaging layer is only a client-side thing to manage received message data

Jun 03 17:18:39 <J_K9> are we talking about the same messaging layer? :/

Jun 03 17:18:47 <clsk> J_K9: the server will have one too.

Jun 03 17:18:55 <Cupu> we should probably draw a line here

Jun 03 17:18:55 <clsk> hm

Jun 03 17:18:57 <clsk> apparently not.

Jun 03 17:19:03 <clsk> although

Jun 03 17:19:09 <J_K9> clsk - i'm sorry, you're right; it's required for delayed messaging

Jun 03 17:19:25 <clsk> J_K9: we're definitively not talking about the same thing here.

Jun 03 17:19:27 <J_K9> we should separate that from the storage subsystem

Jun 03 17:19:27 <beyondd1> And what're those code you just showed?

Jun 03 17:19:49 <Cupu> at which point did you disconnect David?

Jun 03 17:19:52 <clsk> beyondd1: Ananth wanted an example of how it would work.

Jun 03 17:20:04 <beyondd1> I don't when I got disconnected.

Jun 03 17:20:13 <clsk> There would be a big difference though between that and what ours would look like.

Jun 03 17:20:15 <beyondd1> All of the sudden, the chatroom got quiet.

Jun 03 17:20:17 <beyondd1> haha

Jun 03 17:20:36 <Cupu> I think someone should quickly make a resume of the messaging platform (internal mesaging platform that is)

Jun 03 17:20:38 <J_K9> ok, let us change our terminology. the Messaging Layer involves Users sending email-like messages to one another. Communication between Utilities will henceforth be referred to as “communication”/-ate etc

Jun 03 17:20:42 <Cupu> David: hehehe

Jun 03 17:21:12 <clsk> hm

Jun 03 17:21:16 <clsk> the communication layer?

Jun 03 17:21:37 <J_K9> that's good enough for me :) or feature communication layer, whatever you're more comfortable with

Jun 03 17:21:39 <clsk> Inter-Utility Communication? :)

Jun 03 17:21:50 <beyondd1> umm..

Jun 03 17:21:50 <J_K9> well, it's not only Utilities, so… :)

Jun 03 17:21:50 <Cupu> :)

Jun 03 17:22:04 <Cupu> incomm .. for internal communication :)))

Jun 03 17:22:06 <Jef1> Will there be Utility-Utility communication?

Jun 03 17:22:10 <J_K9> yes

Jun 03 17:22:12 <Cupu> :)

Jun 03 17:22:20 <J_K9> Cupu - hehe! yes, that's not half bad!

Jun 03 17:22:22 <Cupu> Well basically that's what we've been arguing about :)

Jun 03 17:22:27 <beyondd1> umm

Jun 03 17:22:27 <clsk> Jef1: Yes, that's the main purpose of the communication system

Jun 03 17:22:32 <Cupu> It seems we're down to code-names now

Jun 03 17:22:34 <J_K9> indeed

Jun 03 17:22:40 <Cupu> I say spearhead (I'll shut up)

Jun 03 17:22:43 <Jef1> What does a Utility do when it receives a message but it's not in receiving mode (if that exists)?

Jun 03 17:22:46 <J_K9> which is good - we will avoid further confusion

Jun 03 17:22:55 <clsk> that doesn't exist.

Jun 03 17:23:01 <J_K9> it does

Jun 03 17:23:03 <Cupu> I t will always receive

Jun 03 17:23:03 <clsk> an utility should always be expecting messages.

Jun 03 17:23:08 <Cupu> it can just ignore what it doesn't lkike

Jun 03 17:23:08 <Jef1> Ah!

Jun 03 17:23:10 <beyondd1> communication layer is utility communication?

Jun 03 17:23:13 <clsk> exactly.

Jun 03 17:23:19 <beyondd1> networking is client and server?

Jun 03 17:23:19 <J_K9> but it may not be able to handle it if the functionality has not been implemented?

Jun 03 17:23:27 <clsk> beyondd1: Yes.

Jun 03 17:23:29 <Cupu> of course

Jun 03 17:23:31 <clsk> right beyondd1

Jun 03 17:23:36 <J_K9> e.g. the Notes Utility might know that any data it receives from another Utility should be added to a new note

Jun 03 17:23:43 <Jef1> So every client IS a server? (speaking client-server communication here)

Jun 03 17:23:46 <beyondd1> that doesn't sound right to me.

Jun 03 17:23:58 <Cupu> Jef1: Basically a solitary developer should not imagine that other utilities are there to serve him

Jun 03 17:24:09 <clsk> Jef1: hm Why would you say that?

Jun 03 17:24:14 <Cupu> He should read up on the docs .. and if he finds something that helps him .. he'll use that ..

Jun 03 17:24:21 <J_K9> beyondd1 - how about internal communication layer then for inter-feature/Utility communication?

Jun 03 17:24:29 <beyondd1> I think we can have a communication layer

Jun 03 17:24:50 <beyondd1> but on top of that, there will be messaging layer and client-server layer

Jun 03 17:25:06 <clsk> hm We could do that too.

Jun 03 17:25:20 <clsk> That would make it a little bit more complicated, but it's possible to do that too.

Jun 03 17:25:24 <Cupu> Of course client side utilities will have to talk to server side utilities

Jun 03 17:25:32 <beyondd1> I think that's more reasonable. Because the networking layer that we use to have can be used for utility to utility communication if coded correctly.

Jun 03 17:25:38 <Cupu> but .. that's another story, a story ontop of the networking layer

Jun 03 17:25:46 <clsk> hm actually

Jun 03 17:25:54 <Cupu> beyondd1: I think that's overkill

Jun 03 17:26:00 <J_K9> as do I

Jun 03 17:26:06 <J_K9> we're complicating things

Jun 03 17:26:08 <clsk> that's the way I first designed the network code I was doing last weekend beyondd1.

Jun 03 17:26:14 <clsk> so yes, it should be that hard.

Jun 03 17:26:22 <Cupu> although something good to note because generarly what I think is not the norm :)

Jun 03 17:26:30 <J_K9> hehe

Jun 03 17:26:45 <Cupu> so it's definately something to take into account

Jun 03 17:27:12 <Cupu> Can we have the incomm (hehe) layer noted down now .. and If we go David's way we'll just remove that?

Jun 03 17:27:20 <Cupu> I mean .. it will still be the layer .. but on the same codebase

Jun 03 17:27:32 <J_K9> Messaging Layer = email-like messages sent from User to User on a Server. Internal Communication Layer = Utility to Utility data transmission. Just to clarify again :)

Jun 03 17:27:54 <beyondd1> that's where I'm confused.

Jun 03 17:28:26 <clsk> J_K9: we said that's going to be an Utility (the messaging layer).

Jun 03 17:29:01 <clsk> that will sit on top of the utility API

Jun 03 17:29:12 <beyondd1> we're using asio, so the communication is either done thru TCP/IP or UDP.

Jun 03 17:29:16 <beyondd1> And we wrap around that

Jun 03 17:29:16 <J_K9> clsk - it's a Utility in the sense that it will sit on top of everything else, but it will not be a Utility as in a Utility within a Workplace. the Message Center in the Client will sit outside any Workplaces or servers - it is a part of the Client itself.

Jun 03 17:29:26 <beyondd1> and now we're providing 2 addition layers?

Jun 03 17:29:29 <clsk> right

Jun 03 17:29:59 <Cupu> David .. the Utilities (as long as they're all clientside) can talk to one another … and because this is an itchy topic .. we'd probably want to keep that as simple as possible

Jun 03 17:30:00 <clsk> Still, it's an utility and it's not part of the core.

Jun 03 17:30:06 <clsk> which is what we're discussing now.

Jun 03 17:30:14 <Cupu> Clientside or serveside .. damn I hate writing incomplete things

Jun 03 17:30:15 <clsk> this is why we're all confused.

Jun 03 17:30:20 <J_K9> yes, you are right

Jun 03 17:30:31 <beyondd1> i'm still confuse… Save me

Jun 03 17:30:37 <Cupu> Can we pause a little

Jun 03 17:30:39 <clsk> Lets concentrate on the core only.

Jun 03 17:30:46 <clsk> beyondd1. What don't you understand?

Jun 03 17:30:46 <Cupu> and have 1 person make a quick tale of everything?

Jun 03 17:31:16 <beyondd1> How about I talk? And you answer question?

Jun 03 17:31:16 <J_K9> Ok, how about this terminology: plugins is everything that sits on top of all of the layers. *Utilities* are the plugins that are used within Workplaces and whose data is restricted to that Workplace. Is that ok?

Jun 03 17:31:24 * beyonddc has quit (Connection timed out)

Jun 03 17:31:36 <clsk> ok

Jun 03 17:31:51 <Cupu> cool

Jun 03 17:31:52 <clsk> lets concentrate on the core for today though :)

Jun 03 17:31:56 <J_K9> ok

Jun 03 17:31:59 <beyondd1> I thought utility and plugin is the same

Jun 03 17:32:01 <J_K9> but just for the future :)

Jun 03 17:32:08 <Cupu> David: it is

Jun 03 17:32:13 <beyondd1> okay

Jun 03 17:32:18 <clsk> we just redifined it.

Jun 03 17:32:29 <clsk> So a plugin is a plugin. What everbody knows as a plugin.

Jun 03 17:32:31 <J_K9> A Utility is a plugin, but a plugin isn't a Utility. e.g. the Message Center is a plugin but not a Utility

Jun 03 17:32:31 <Cupu> I think we discussed this just at the start .. but then the “message” storm came .. and we got a little confused

Jun 03 17:32:37 <clsk> but a Utility is a special type of plugin.

Jun 03 17:32:50 <beyondd1> o…….k

Jun 03 17:32:50 <Cupu> right right ..

Jun 03 17:32:57 <clsk> got it David?

Jun 03 17:33:07 <beyondd1> digesting…

Jun 03 17:33:10 <clsk> heh

Jun 03 17:33:13 <clsk> ok.

Jun 03 17:33:13 <J_K9> :)

Jun 03 17:33:21 <Cupu> Because as David also said .. we're providing an api/abstraction whatever

Jun 03 17:33:30 <clsk> Sooooo.. we still have Directory, Network and Storage systems.

Jun 03 17:33:31 <Cupu> and one of those specializations on top of that .. will be a utility interface

Jun 03 17:33:53 <Cupu> or we could just drop the word

Jun 03 17:33:58 <Cupu> Alan .. so that's core right?

Jun 03 17:34:16 <beyondd1> , that just confuse the heck of out of me. I read it 5 times already. “A utility is a plugin, but a plugin isn't a utility”.

Jun 03 17:34:24 <beyondd1> omg… am I taking a philosphy class?

Jun 03 17:34:25 <beyondd1> :x

Jun 03 17:34:27 <Cupu> :))

Jun 03 17:34:50 <J_K9> lol, sorry. A Utility is a special type of plugin whose data is only available to the members of a single Workplace. How about that? :)

Jun 03 17:35:09 <clsk> heh

Jun 03 17:35:15 <clsk> Right Stefan.

Jun 03 17:35:16 <J_K9> A plugin is anything that sits on top of all of Mira's layers which uses their functionality to work.

Jun 03 17:35:18 <Cupu> So basically .. until we define/code strong parts of the 3 (am I right?!) core subsystems …. we shouldn't think about anything else

Jun 03 17:35:19 <clsk> here's what we have so far:

Jun 03 17:35:22 <clsk> - Directory

Jun 03 17:35:22 <clsk> - Authentication

Jun 03 17:35:22 <clsk> - Querying

Jun 03 17:35:22 <clsk> - Network

Jun 03 17:35:22 <clsk> - Network Communication

Jun 03 17:35:23 <clsk> - Internal Communication

Jun 03 17:35:24 <Cupu> I mean except the design team :)

Jun 03 17:35:25 <clsk> - Storage

Jun 03 17:35:27 <clsk> - Simple file replacement.

Jun 03 17:35:29 <clsk> - Subversion

Jun 03 17:35:38 <clsk> right Stefan.

Jun 03 17:35:47 <clsk> At least I think we should work that way.

Jun 03 17:35:49 <Cupu> I liked it when they were 3 actualy :)

Jun 03 17:35:56 <clsk> They are.

Jun 03 17:35:56 <Cupu> I agree

Jun 03 17:36:02 <clsk> the other are subsystems.

Jun 03 17:36:07 <Cupu> I know I know .. just joking

Jun 03 17:36:12 <clsk> ah :)

Jun 03 17:36:12 <clsk> heh

Jun 03 17:36:18 <J_K9> should Internal Communication be within Network?

Jun 03 17:36:24 <clsk> actually

Jun 03 17:36:30 <clsk> rename that to Communication

Jun 03 17:36:43 <clsk> so

Jun 03 17:36:43 <clsk> - Communication

Jun 03 17:36:43 <clsk> - Network Communication

Jun 03 17:36:43 <clsk> - Internal Communication

Jun 03 17:36:47 <Cupu> also can subversion please be version control?

Jun 03 17:36:50 <clsk> ok

Jun 03 17:36:51 <J_K9> yes

Jun 03 17:36:52 <clsk> yes

Jun 03 17:36:56 <Cupu> What if mars attacks and erases subversin from our minds

Jun 03 17:37:01 <J_K9> and 'simple file replacement' database instead?

Jun 03 17:37:02 <J_K9> lol

Jun 03 17:37:18 <Cupu> Also I've been a little sloppy and missed what simple file replacement is?

Jun 03 17:37:20 <clsk> that's different. Simple file replacement means erase the old file, create a new one.

Jun 03 17:37:27 * beyonddc (n=David@c-66-30-134-52.hsd1.ma.comcast.net) has joined #mira

Jun 03 17:37:31 <clsk> I'll include database to it.

Jun 03 17:37:33 <beyonddc> …

Jun 03 17:37:37 <beyonddc> I got disconnected again

Jun 03 17:37:46 <J_K9> clsk - I know, but I think we decided yesterday to use the version control system for any file-based Utilities

Jun 03 17:37:54 <clsk> hm

Jun 03 17:37:55 <Cupu> I mean .. If we have a version control abstraction .. we could have a paralel version control .. that simply doesn't version anything?!

Jun 03 17:38:22 <clsk> We should probably have more options for utility developer.

Jun 03 17:38:27 <Jef1> Guys, much as I like the discussion, I have a utility downstairs I want to communicate with… called W.I.F.E. So I'm off, but we'll meet again! I'll leave my IRC-utility on to see your messages :P

Jun 03 17:38:29 <Cupu> clsk: Right .. got it now .. but should it appear as a separate subsystem

Jun 03 17:38:29 <clsk> Maybe he doesn't need that much

Jun 03 17:38:39 <beyonddc> have fun Jeff

Jun 03 17:38:43 <J_K9> Haha! Thanks for joining us Jeff ;)

Jun 03 17:38:58 <Cupu> Jef1:Very nice meeting you …. have a great day

Jun 03 17:38:59 <clsk> bye Jef1

Jun 03 17:39:12 <Jef1> BYE!

Jun 03 17:39:12 <J_K9> clsk - can you please post the newest version of the subsystems?

Jun 03 17:39:15 <J_K9> :)

Jun 03 17:39:19 <clsk> ok

Jun 03 17:39:21 <J_K9> bye!

Jun 03 17:39:31 <clsk> - Directory

Jun 03 17:39:31 <clsk> - Authentication

Jun 03 17:39:31 <clsk> - Querying

Jun 03 17:39:31 <clsk> - Communication

Jun 03 17:39:31 <clsk> - Network Communication

Jun 03 17:39:32 <clsk> - Internal Communication

Jun 03 17:39:32 <Cupu> Alan: I think you're right though .. but I would have liked the subsystems not to be to clubbered (rather the sub-subsystems)

Jun 03 17:39:36 <clsk> - Storage

Jun 03 17:39:36 <clsk> - Simple file replacement.

Jun 03 17:39:38 <clsk> - Version Control

Jun 03 17:39:40 <clsk> - Database

Jun 03 17:39:52 <beyonddc> Yea.. that was my question earlier. What's simple file replacement

Jun 03 17:40:04 <Cupu> :D

Jun 03 17:40:06 <clsk> a new file is created and the old one deleted.

Jun 03 17:40:14 <clsk> we'll need a better name for it

Jun 03 17:40:15 <Cupu> I don't get database there .. database for what?

Jun 03 17:40:25 <clsk> Cupu: For storing information.

Jun 03 17:40:33 <Cupu> :) .. what kind of information?

Jun 03 17:40:35 <clsk> Not all utilities are going to be file-based.

Jun 03 17:40:37 <clsk> Notes.

Jun 03 17:40:40 <clsk> Messages.

Jun 03 17:40:41 <clsk> Emails

Jun 03 17:40:48 <clsk> hmm just to name a few

Jun 03 17:40:49 <Cupu> shouldn't database be a thing that the directory can use, or the storage .. or so on?

Jun 03 17:41:00 <Cupu> or the communication .. or whatever

Jun 03 17:41:09 <clsk> hm no

Jun 03 17:41:22 <J_K9> it's what Alan said it's for - to store the data of non-files-based Utilities

Jun 03 17:41:27 <clsk> We're trying to separate systems so it's a cleaner and simpler design.

Jun 03 17:42:00 <Cupu> Hmm .. if it's the general conseus (is this a word?!) I'll go along with it .. and I'm sure tonight it will bang me on the head and I'll say “Ohhh that's right!!”

Jun 03 17:42:19 <clsk> it probably will ;)

Jun 03 17:42:29 <beyonddc> Directory in your sense is just for authentication?

Jun 03 17:42:35 <Cupu> so what you're saying is I should sleep with a helmet on?

Jun 03 17:42:36 <J_K9> ok, I've just finally understood the whole layered system :)

Jun 03 17:42:38 <beyonddc> and querying is for querying user info?

Jun 03 17:42:47 <clsk> no beyonddc. Not in mine anyways.

Jun 03 17:43:04 <beyonddc> okay, can you explain a little about what you mean by directory querying?

Jun 03 17:43:05 <clsk> yes beyonddc.

Jun 03 17:43:07 <beyonddc> o

Jun 03 17:43:16 <J_K9> beyonddc - Querying is for finding out user roles (e.g. Project Manager in Workplace X, Member of Workplace Y etc)

Jun 03 17:43:20 <clsk> User info, permissions, and workgroup info.

Jun 03 17:43:23 <beyonddc> okay

Jun 03 17:43:31 <clsk> we can add more stuff later of course.

Jun 03 17:43:31 <J_K9> plus finding out other users on the server when sending them a message, for example

Jun 03 17:43:34 <clsk> But those are the basics.

Jun 03 17:43:42 <J_K9> yes

Jun 03 17:43:57 <Cupu> Right .. that actually also made it clear for me .. thanks

Jun 03 17:44:06 <beyonddc> internal communication doesn't go over network, right?

Jun 03 17:44:08 <J_K9> no

Jun 03 17:44:10 <clsk> correct.

Jun 03 17:44:12 <beyonddc> good

Jun 03 17:44:20 <Cupu> one thing just so I didn't miss anything

Jun 03 17:44:24 <clsk> so we're all on the same page now?

Jun 03 17:44:27 <J_K9> great! :)

Jun 03 17:44:34 <J_K9> Cupu - yes?

Jun 03 17:44:39 <beyonddc> I think so, I do want to draw the layer diagram to ensure I understand everything

Jun 03 17:44:45 <beyonddc> and you guys can correct me if I'm wrong.

Jun 03 17:44:47 <Cupu> It's very possible that the directory willl use a database .. as it's possible for the storage and so one right?

Jun 03 17:44:53 <clsk> Please do beyonddc.

Jun 03 17:44:56 <J_K9> beyonddc - please do. upload it to the wiki and then send an email to the list :)

Jun 03 17:45:06 <beyonddc> ok

Jun 03 17:45:06 <clsk> Cupu: Correct.

Jun 03 17:45:26 <clsk> shall we discuss the three systems now?

Jun 03 17:45:26 <J_K9> Indeed. Directory will store user data in the Database layer

Jun 03 17:45:52 <Cupu> right .. I still think It should be remodelled just a little bit .. but I'll shut up and if in a couple of days I still don't get it .. I'll write an email (where I'll actually think .. as opposed to what I'm doing now)

Jun 03 17:46:08 <clsk> Cupu: Express your ideas.

Jun 03 17:46:12 <clsk> way

Jun 03 17:46:13 <clsk> hm

Jun 03 17:46:20 <clsk> was that spelt right?

Jun 03 17:46:26 <J_K9> hmm… about what I just said though - we'll need to make sure we secure that properly so that malicious Utilities cannot access user data (i.e. the Directory layer's data) in the database

Jun 03 17:46:34 <Cupu> don't ask me :)

Jun 03 17:46:35 <clsk> I don't think so

Jun 03 17:46:35 <beyonddc> i know you spelled spell wrong

Jun 03 17:46:38 <clsk> say what's on your mind ;)

Jun 03 17:46:40 <beyonddc> we all had bad keyboards

Jun 03 17:46:48 <Cupu> Express is right though ..

Jun 03 17:46:54 <J_K9> lol

Jun 03 17:47:05 <Cupu> we should change keyboads just so we confuse them (change between ourselves I mean)

Jun 03 17:47:08 <clsk> right J_K9.

Jun 03 17:47:14 <J_K9> ok

Jun 03 17:47:23 <J_K9> we should all buy the same keyboard - that way, no more lies :p

Jun 03 17:47:29 <clsk> Cupu: what are your suggestions?

Jun 03 17:47:32 <clsk> heh

Jun 03 17:47:33 <clsk> yea

Jun 03 17:47:56 <Cupu> I think (suposedly) that the utility will always remain a little bit of a way for a malicious person (is there such a thing) to compromise a server

Jun 03 17:48:00 <Cupu> or the user data and such

Jun 03 17:48:07 <beyonddc> before we talk about each layer

Jun 03 17:48:11 <J_K9> true, but we need to do our best to prevent that

Jun 03 17:48:13 <beyonddc> let's talk about security

Jun 03 17:48:22 <J_K9> I'm sure we'll discuss security requirements in more detail in the SRS

Jun 03 17:48:24 <J_K9> for each layer

Jun 03 17:48:29 <beyonddc> okay

Jun 03 17:48:32 <Cupu> so we should definately employ certain tactics to minimze that (I don't think we can prevent it 100% while at the same time be ver extensible)

Jun 03 17:48:53 * ananth has quit (Connection timed out)

Jun 03 17:48:53 <J_K9> I think we can. as long as we think it through properly, it should be possible

Jun 03 17:48:55 <clsk> I think we can.

Jun 03 17:49:02 <beyonddc> ananth left awhile ago huh?

Jun 03 17:49:06 <beyonddc> we bored him

Jun 03 17:49:07 <clsk> I think so.

Jun 03 17:49:09 <J_K9> lol

Jun 03 17:49:10 <Cupu> :D

Jun 03 17:49:13 <beyonddc> he wants to know about his layer

Jun 03 17:49:14 <clsk> He's been quiet for most of the meeting.

Jun 03 17:49:20 <J_K9> it's probably late over there

Jun 03 17:49:30 <Cupu> So we're aiming for a way that no Server Utility has access to user data?

Jun 03 17:49:40 <J_K9> no

Jun 03 17:49:43 * ananth (n=ananthbv@59.92.193.40) has joined #mira

Jun 03 17:49:44 <clsk> hm no

Jun 03 17:49:44 <Cupu> (just an example)

Jun 03 17:49:48 <beyonddc> ananth is back!

Jun 03 17:49:49 <J_K9> but it must have access only to *some* data

Jun 03 17:49:52 <Cupu> hehe .. spoke to soon again

Jun 03 17:49:54 <J_K9> hey ananth :)

Jun 03 17:49:58 <ananth> sorry all, got disconnected

Jun 03 17:50:03 <J_K9> np

Jun 03 17:50:05 <ananth> hi Max

Jun 03 17:50:15 <clsk> You've been quiet ananth.

Jun 03 17:50:17 <Cupu> Max .. I'm thinking that if an admin is not carefull and installs an un-trustworthy utility

Jun 03 17:50:30 <Cupu> as long as that utility gained access to any kind of data .. the server is compromised

Jun 03 17:50:31 <ananth> i was not online for the last 15 mins

Jun 03 17:50:34 <J_K9> then the data of other Utilities in the Workplace could be compromised

Jun 03 17:50:39 <Cupu> that's what I dpon't think we can avoid ..

Jun 03 17:50:43 <J_K9> but we should restrict it to *that* Utility alone

Jun 03 17:50:58 <J_K9> so it can be avoided to a certain extent as long as we segregate data properly

Jun 03 17:51:01 <Cupu> of course .. I just don't want us to get the false sense of security

Jun 03 17:51:05 <ananth> whats the topic of discussion now?

Jun 03 17:51:09 <clsk> Cupu: data such as privileges and trivial user information is OK. things we cannot allow are malicious utilities messing with files.

Jun 03 17:51:10 <J_K9> sorry, I meant restrict it to that Workplace

Jun 03 17:51:17 <J_K9> ananth: security

Jun 03 17:51:18 <beyonddc> security is the topic right now

Jun 03 17:51:25 <Cupu> That will also reflect in distribution and verification of utilities before install

Jun 03 17:51:29 <ananth> ok

Jun 03 17:51:33 <J_K9> Cupu - yes.

Jun 03 17:51:47 <Cupu> Trusted computing will help us a lot and make our life easier in that regard (joking .. joking)

Jun 03 17:51:51 <J_K9> oh, the installation, updatability and management of Utilities is something we also need to talk about

Jun 03 17:51:56 <J_K9> lol Cupu

Jun 03 17:52:35 <beyonddc> i think there should be a security layer underneath the utility layer.

Jun 03 17:52:44 <Cupu> definately

Jun 03 17:52:52 <J_K9> could security not be implemented in the utility API layer?

Jun 03 17:52:55 <Cupu> if we're going to have interfaces for the utilities

Jun 03 17:53:04 * beyondd1 has quit (Connection timed out)

Jun 03 17:53:06 <Cupu> we're definately going to have restrictions and levels of access for each interface

Jun 03 17:53:13 <J_K9> yes, certainly

Jun 03 17:53:15 <beyonddc> or security is build right into the utility API

Jun 03 17:53:21 <Cupu> Right .. so that security is mandatory .. and I agree with all that was said

Jun 03 17:53:23 <J_K9> that's what I was thinking

Jun 03 17:53:29 <Cupu> actually under it .. but yes .. same thing

Jun 03 17:53:39 <Cupu> The utility api should not know how much access it has

Jun 03 17:53:48 <J_K9> well, under it in terms of layer structure but in it in terms of code? :)

Jun 03 17:53:49 <Cupu> it should either succeed at something or fail (because of low privileges)

Jun 03 17:53:52 <J_K9> yes

Jun 03 17:53:57 <J_K9> precisely

Jun 03 17:54:03 <J_K9> fail with an error, of course

Jun 03 17:54:03 <Cupu> that's not hard to implement

Jun 03 17:54:13 <Cupu> it's a good thing we have it in sight from the start

Jun 03 17:54:17 <J_K9> yes

Jun 03 17:54:27 <Cupu> it's just a matter of checking privileges .. easy easy easy

Jun 03 17:54:28 <beyonddc> then a security layer underneath utility layer

Jun 03 17:54:33 <Cupu> (hope I don't swallow my words)

Jun 03 17:54:40 <J_K9> lol

Jun 03 17:54:48 <Cupu> well it can be part of the api (I just contradicted mysel I know)

Jun 03 17:54:57 <Cupu> I'm afraid of defining to many layers

Jun 03 17:55:02 <clsk> <beyonddc> then a security layer underneath utility layer → I think that's a good idea.

Jun 03 17:55:08 <beyonddc> no Stefen

Jun 03 17:55:12 <J_K9> not only checking privileges, but making sure that a Utility cannot delete data in other Utilities and cannot access ANY Utility data from other Workplaces :)

Jun 03 17:55:22 <Cupu> of course of course .. but those are details

Jun 03 17:55:24 <beyonddc> we need to clearly identify the role of each layer.

Jun 03 17:55:29 <J_K9> yes

Jun 03 17:55:29 <Cupu> we'll define a set o factions

Jun 03 17:55:32 <beyonddc> Making a layer doing multiple things is actually more confusing

Jun 03 17:55:40 <Cupu> of actions* .. and restrict on those and so on

Jun 03 17:55:41 <J_K9> should security layer be beneath Utility layer though?

Jun 03 17:55:49 <Cupu> well it has to be

Jun 03 17:55:59 <beyonddc> Yea

Jun 03 17:56:00 <J_K9> ah, yes

Jun 03 17:56:02 <J_K9> ok

Jun 03 17:56:04 <Cupu> Implemented in what the utility api is using as an api :) (how does that sound)

Jun 03 17:56:04 <J_K9> got it :)

Jun 03 17:56:09 <J_K9> lol

Jun 03 17:56:16 <J_K9> intelligible ;)

Jun 03 17:56:35 <Cupu> Right so .. we have loads of planning to do

Jun 03 17:56:37 <clsk> Also, the internal communication system will implement SOME security.

Jun 03 17:56:37 <J_K9> yes

Jun 03 17:56:49 <J_K9> Alan - yes :)

Jun 03 17:56:51 <beyonddc> right now we can just briefly use the term security layer as the security we'll be providing to utility. The definiation of security will leave to the SRS which Max will have fun with

Jun 03 17:57:03 <Cupu> Alan .. can we safely say .. that we have enaugh knowledge to at least think about code (if not write some stubs) in regard to the 3 major layers?

Jun 03 17:57:12 <beyonddc> I'm just going to give all the hard work to Max. :x

Jun 03 17:57:12 <J_K9> Cupu - I think our best bet is to do a diagram of the layer structure. beyonddc, are you up for that?

Jun 03 17:57:21 <J_K9> lol

Jun 03 17:57:23 <clsk> Yes Stefan.

Jun 03 17:57:25 <J_K9> thanks David :p

Jun 03 17:57:26 <beyonddc> Yes, I'm doing that Max

Jun 03 17:57:32 <Cupu> Max .. of course .. I'm not rushing things .. only want to multi-task a little :)

Jun 03 17:57:42 <J_K9> yes, that's perfectly fine! by all means do so :)

Jun 03 17:57:47 <Cupu> Alan: Great!

Jun 03 17:57:59 <clsk> I could do some basic coding of the three basic layers (on the server) so we have an idea of how they work.

Jun 03 17:58:17 <clsk> Of course this will change later on and/or might not be used at all in the final implementation.

Jun 03 17:58:26 <J_K9> yes

Jun 03 17:58:27 <Cupu> Of course

Jun 03 17:58:35 <beyonddc> sure

Jun 03 17:58:52 <beyonddc> 3 lines of comment, 1 line of code

Jun 03 17:58:53 <Cupu> one thing though (I know it's early) .. but at some point we'll add the GUI layer too (I mean support; always me and the GUI)

Jun 03 17:58:54 <beyonddc>

Jun 03 17:58:55 <clsk> someone needs to do the same on the client though. I'm not supercoder yet ;)

Jun 03 17:59:00 <Cupu> yeah David :)

Jun 03 17:59:11 <Cupu> clsk: Definatey sign me up there

Jun 03 17:59:22 <Cupu> although the storage/filesystem code will be largely shared

Jun 03 17:59:29 <clsk> cool

Jun 03 17:59:33 <J_K9> Ananth will have fun with that :)

Jun 03 17:59:40 <ananth> :)

Jun 03 17:59:47 <clsk> the Storage system will probably just be a skeleton and not functional.

Jun 03 17:59:47 <J_K9> hehe!

Jun 03 17:59:53 <clsk> for this weekend

Jun 03 17:59:55 <J_K9> yes

Jun 03 18:00:00 <clsk> week

Jun 03 18:00:01 <clsk> at least

Jun 03 18:00:05 <J_K9> an outline of the API it would provide would be good though

Jun 03 18:00:09 <clsk> btw.

Jun 03 18:00:16 <ananth> yes, i'll work on that

Jun 03 18:00:19 <J_K9> thanks ananth

Jun 03 18:00:22 <beyonddc> If the storage system is base on a client/server model, should it be setting on top of the communication layer?

Jun 03 18:00:33 <J_K9> no code it required yet, just an outline to help us define the requirements and identify missing ones :)

Jun 03 18:00:35 <Cupu> well it's not

Jun 03 18:00:38 <Cupu> I think

Jun 03 18:00:39 <clsk> by the way. I'll be going on vacation in 2 weeks. And then I'll be going to iraq the week after I come back and will probably be offline for over a month.

Jun 03 18:01:03 <clsk> so I won't be of much help for a while after the 15th of this month

Jun 03 18:01:03 <beyonddc> Alan, it will be great if you can send us your working code so we can play with while you're gone.

Jun 03 18:01:11 <clsk> I will

Jun 03 18:01:18 <J_K9> clsk - that's alright. if you could give us approximate dates nearer the time that'd be great! best of luck btw.

Jun 03 18:01:33 <clsk> this is why I'm trying to get some of the design done so I can send you guys some working code to play with before I go.

Jun 03 18:01:35 <ananth> Alan, i think i'll be bugging for some coding help. do make sure you have access to email :)

Jun 03 18:01:49 <beyonddc> I'll make ensure we'll make a 360% change on your code and when you come back, you'll not recongize that you actually was the original author.

Jun 03 18:01:52 <ananth> i mean technical help

Jun 03 18:01:56 <J_K9> lol beyonddc

Jun 03 18:02:01 <Cupu> :))

Jun 03 18:02:04 <clsk> I'll be able to check email, but won't be as active as now until I get settled over there.

Jun 03 18:02:05 <ananth> :))

Jun 03 18:02:14 <clsk> heh I know.

Jun 03 18:02:30 <Cupu> how long's the service there?

Jun 03 18:02:37 <clsk> 15 months as of right now.

Jun 03 18:02:41 <J_K9> wow

Jun 03 18:02:41 <Cupu> (this is just out of curiosity and totaly unrelated to mira)

Jun 03 18:02:51 <clsk> but I'll have internet while there.

Jun 03 18:02:51 <beyonddc> Ananth, just send any coding help thru the mailing list. I could help you too if I know the answer.

Jun 03 18:02:58 <clsk> It'll just take a while to get settled.

Jun 03 18:03:14 <Cupu> beyonddc: oh definately .. that's the code pipeline :)

Jun 03 18:03:23 <Cupu> or an area in the svn repository

Jun 03 18:03:31 <clsk> speaking of svn

Jun 03 18:03:36 <clsk> do we really want svn?

Jun 03 18:03:37 <J_K9> I'm sorry guys, I have to leave now. Can we discuss this further on the mailing list? Let's make sure we keep in touch and perhaps we can have another meeting next Saturday/Sunday :)

Jun 03 18:03:48 <clsk> cool

Jun 03 18:03:59 <beyonddc> Max, can you put the chat log in the arhieve?

Jun 03 18:04:01 <clsk> yes I propose we schedule another meeting for saturday/sunday at the same time.

Jun 03 18:04:06 <beyonddc> I need it for the diagram.

Jun 03 18:04:06 <J_K9> I'll upload the log and, if you guys continue the discussion, please add the rest of it.

Jun 03 18:04:15 <J_K9> david - of course :)

Jun 03 18:04:18 <clsk> btw, Max. your ip changed.

Jun 03 18:04:23 <clsk> so I can't access the dev box.

Jun 03 18:04:25 <J_K9> really? rats

Jun 03 18:04:27 <J_K9> I'm sorry

Jun 03 18:04:31 <clsk> it's ok.

Jun 03 18:04:32 <J_K9> I'll set up DynDNS if I can :)

Jun 03 18:04:36 <clsk> cool

Jun 03 18:04:48 <beyonddc> i use no-ip.com as dyndns

Jun 03 18:04:52 <Cupu> Max .. you can use a free domain

Jun 03 18:04:55 <Cupu> subdomain

Jun 03 18:05:08 <Cupu> toghether with a client that updates the IP .. so alan cand have no problems accesing

Jun 03 18:05:10 <J_K9> yes, I know - I just haven't got round to setting it up yet. hehe!

Jun 03 18:05:13 <clsk> I'm lucky. My ip is supposed to be dynmic. but it hasn't changed since I got the service.

Jun 03 18:05:19 <Cupu> again .. what david said :)

Jun 03 18:05:22 <J_K9> indeed

Jun 03 18:05:31 <clsk> even disconnecting the router doesn't change my ip.

Jun 03 18:05:34 <Cupu> clsk: When I said svn .. I mean any repository .. you're right

Jun 03 18:05:36 <clsk> I do get it through dhcp though.

Jun 03 18:05:43 <clsk> Cupu, I mean for development.

Jun 03 18:05:44 <Cupu> maybe you have a lifetime lease :D

Jun 03 18:05:49 <clsk> heh

Jun 03 18:05:53 <clsk> that's what it looks like.

Jun 03 18:05:54 <Cupu> well we need some source control

Jun 03 18:06:00 <clsk> right

Jun 03 18:06:01 <Cupu> damn .. I read it wrong

Jun 03 18:06:03 <Cupu> sorry

Jun 03 18:06:07 <clsk> beyonddc here?

Jun 03 18:06:07 <Cupu> of course .. for development

Jun 03 18:06:17 <clsk> he knows a lot more than I do about version control

Jun 03 18:06:22 <J_K9> well, thank you all for the great meeting - until our next conversation on the mailing list! ;)

Jun 03 18:06:29 <clsk> bye Max

Jun 03 18:06:35 <ananth> bye, Max

Jun 03 18:06:35 <J_K9> bye all

Jun 03 18:06:47 <Cupu> bye bye Max

Jun 03 18:06:48 <clsk> ananth do you have any experience with version control systems?

Jun 03 18:07:00 <ananth> only in using it