Re: Progress

Thurston, that sounds like a reasonable decision. :) If you need any
help setting up your Linux environment in the future, please do ask.

There are a few developers (excluding Alan and Fred) who have yet to
reply, but thank you to all of you who have taken this decision and
responded. Now let's try to pick things up and get some code flowing;
4 points to the next person to commit a revision to the repository,
starting now! ;)

On 28/11/2007, Thurston Stone <tstone2077@...> wrote:
> Hello all,
>
> I've been slacking a bit on the development.  I've been trying to find a
> linux distribution I like for my laptop, with little success so far.  I'd
> like to develop Mira using both a linux box and a Windows box... to make
> sure that the GUI compilations/binaries are working from the start.  I think
> I'm going to put that task on the side and start contributing more coding
> here on out.
>
> Thanks,
> Thurston
>
>
>
> From: aib.wolphin@...
> To: mira-development@...
> Date: Wed, 28 Nov 2007 00:17:17 +0000
> Subject: Re: [Mira-development] Progress
>
> David and Naveen, I hope you become adjusted to your new environments (both

Re: Progress

I don't know why I didn't think of it earlier, but VMWare Player would be a great solution for the Linux/Windows programming environments.  I setup a VMWare linux station and it is working very well (I have yet to attempt a compile, but I'll do that soon). 

Just FYI,
Thurston

> Date: Sat, 1 Dec 2007 00:03:23 +0000
> From: aib.wolphin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> To: mira-development-5NWGOfrQmneRv+LV9MX5uv+2+P5yyue3@public.gmane.orgt
> Subject: Re: [Mira-development] Progress
>
> Thurston, that sounds like a reasonable decision. :) If you need any
> help setting up your Linux environment in the future, please do ask.
>
> There are a few developers (excluding Alan and Fred) who have yet to
> reply, but thank you to all of you who have taken this decision and
> responded. Now let's try to pick things up and get some code flowing;
> 4 points to the next person to commit a revision to the repository,
> starting now! ;)
>
> On 28/11/2007, Thurston Stone <tstone2077-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:
> > Hello all,
> >
> > I've been slacking a bit on the development. I've been trying to find a
> > linux distribution I like for my laptop, with little success so far. I'd
> > like to develop Mira using both a linux box and a Windows box... to make
> > sure that the GUI compilations/binaries are working from the start. I think
> > I'm going to put that task on the side and start contributing more coding
> > here on out.
> >
> > Thanks,
> > Thurston
> >
> >
> >
> > From: aib.wolphin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > To: mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > Date: Wed, 28 Nov 2007 00:17:17 +0000
> > Subject: Re: [Mira-development] Progress
> >
> > David and Naveen, I hope you become adjusted to your new environments (both
> > virtual and physical!) soon. :)Farrukh, thanks for getting up to date so
> > quickly. If you have any questions, do not hesitate to post them to the list
> > or, if everything's clear in your mind, please start working on the code
> > whenever you can - I'm sure Alan will appreciate the help! ;)Regards,
> >
> > Max BossinoProject Managerhttp://miragroupware.org
> > On 27 Nov 2007, at 22:01, "naveen akarapu" <naveen.akarapu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Max,
> >
> > I have also been
> > moving, in every way actually. In the last 30 days I have relocated, changed
> > a job and most importantly (for Mira) changed
> > my OS (and a new car too :)).
> >
> > I had to
> > delete my old Slackware 10 and install Debian 4.0 (etch), because I had too
> > many
> > compatibility issues when I tried to change to 2.6 kernel and while
> > installing
> > other development libraries. It was time to change, anyway. Then had a few
> > problems with installing the wireless card driver (tried fw-cutter, didn't
> > work
> > - now back to ndis). If not the new job, the new place is taking more time
> > out
> > of my day with administrative issues.
> >
> > Finally, a
> > couple of days back I checked out the source from SF repository. I guess
> > need to
> > install the wxWidgets and Boost libraries before I can try out the code. So
> > I am inching, rather
> > slowly, towards making a contribution. Thanks for the wake up call
> > though.
> >
> >
> > Thanks
> > Naveen
> >
> > On Nov 27, 2007 10:18 AM, FARRUKH RAZA <raza1698-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org
> > > wrote:
> >
> >
> >
> >
> > I have read the documentation of the project and would be providing input
> > pretty soon.
> >
> > Farrukh Raza
> >
> >
> >
> > > Date: Tue, 27 Nov 2007 10:11:03 -0500
> > > From: beyonddc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > > To: mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >
> > > Subject: Re: [Mira-development] Progress
> > >
> > > I would still like to participate in this project but I been very busy
> > > lately because one of the guy here at work left the company and I took
> >
> > > over all his work and deadline is coming so I been working crazy
> > > hours.
> > >
> > > In addition...... even though I'm not moving like Bart but I'm moving
> > > to new computer. LOL! I am going to build a new computer with Core 2
> >
> > > Quad. hehe!!!
> > >
> > > - dc
> > >
> > > On Nov 27, 2007 2:58 AM, J_K9 <aib.wolphin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > Daryl, thank you truly for all your contributions to this project. I
> > respect
> >
> > > > your decision to leave the team and wish you all the best in the future!
> > I
> > > > also hope we'll see you around here again if you ever find some more
> > free
> > > > time.
> > > >
> > > > I am aware that some of you, such as Bart and Fred, are currently either
> >
> > > > moving home, finishing work on another project or doing something which
> > > > temporarily restricts your ability to contribute to Mira. But thank you,
> > > > Bart, for confirming that - I look forward to your contributions!
> >
> > > >
> > > >
> > > >
> > > > On 26/11/2007, Bart Akeley <bart.akeley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > Max, you are right, I have been a slacker due to my cross-country
> >
> > > > > move. However, I am now up and running at the new place, and I will
> > > > > be devoting more time to Mira now that I am settled.
> > > > >
> > > > > On Nov 24, 2007 9:39 AM, Daryl Lee <
> > dlee <at> altaregos.com> wrote:
> > > > > > Max:
> > > > > >
> > > > > > As the "second most prolific" contributor to the project, I
> > appreciate
> >
> > > > > > your excellent note. However, I have come to realize that I am
> > unable
> > > > > > to make any more contributions to the project, for a variety of
> > reasons.
> > > > > > Please feel free to remove me from the mail list and SVN access.
> >
> > > > > >
> > > > > > Thanks for the opportunity to learn a little bit more about the Open
> > > > > > Source process.
> > > > > >
> > > > > > Daryl
> > > > > >
> >
> > > > > >
> > > > > > J_K9 wrote:
> > > > > > > Dear Core Developers,
> > > > > > >
> > > > > > > Many of you have been an integral part of Mira Groupware for
> > months,
> >
> > > > and
> > > > > > > when you joined the project you confirmed that you would be able
> > to
> > > > work
> > > > > > > on it at least 5 hours a week. Most of you have lived up to your
> > word
> >
> > > > > > > and have frequently attended developer meetings, contributed ideas
> > and
> > > > > > > designs to the documentation and generally helped to improve the
> > > > project.
> > > > > > >
> >
> > > > > > > However, at the end of the day, what truly matters to any Open
> > Source
> > > > > > > project is the source code, and that is something that very few of
> > you
> > > > > > > have contributed to. Here are the statistics:
> >
> > > > > > >
> > > > > > > Alan Alvarez: 19 commits
> > > > > > > Daryl Lee: 2 commits
> > > > > > > Thurston Stone: 1 commit
> > > > > > >
> > > > > > > There are currently 9 developers working on this project, only 3
> > of
> >
> > > > whom
> > > > > > > have committed their changes or additions to the source code to
> > Mira's
> > > > > > > SVN repository. That isn't really a great turnout, considering
> > that
> >
> > > > 86%
> > > > > > > of the 22 total code revisions were submitted by Alan.
> > > > > > > As a side-note for the more curious amongst you, the SVN
> > repository
> > > > has
> > > > > > > already been up for around 3 months and 2 weeks.
> >
> > > > > > >
> > > > > > > Of course, I'm not asking you all to give up your day jobs and
> > hack on
> > > > > > > Mira for a living, but I would like to see every one of you
> >
> > > > contributing
> > > > > > > to this project as frequently and as productively as you said you
> > > > would.
> > > > > > > Mira will not go anywhere without your help and contributions, and
> > as
> >
> > > > > > > much as Alan enjoys working on the project I don't think it's fair
> > to
> > > > > > > make him do all the base layer work.
> > > > > > >
> > > > > > > You are all extremely talented and good-willed - if not you
> > wouldn't
> >
> > > > > > > have offered your help in the first place - but now, in its
> > infancy,
> > > > is
> > > > > > > when Mira Groupware needs you most. If you really do want it to
> > become
> > > > a
> >
> > > > > > > reality and use it in the future then your contributions to the
> > source
> > > > > > > code, even if only one or two hours' work a week, will be
> > absolutely
> > > > > > > invaluable.
> >
> > > > > > >
> > > > > > > If you find that you no longer have the time to be one of Mira's
> > Core
> > > > > > > Developers and contribute a couple of hours' worth of work a week
> > to
> >
> > > > > > > this project, please let me know and I will honour your decision
> > and
> > > > > > > attempt to find a replacement. However, the reason I selected each
> > of
> > > > > > > you is because I believed that you would be a brilliant addition
> > to
> >
> > > > the
> > > > > > > group and that, together, you would be the perfect team to make
> > this
> > > > > > > project succeed. Now, it's your turn to prove me wrong or,
> > hopefully,
> > > > > > > right.
> >
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Max Bossino
> > > > > > > Project Manager
> > > > > > >
> > http://miragroupware.org
> > > > > > >
> > > > > > ...
> > > > > > --
> > > > > > Daryl Lee
> > > > > > Open the Present--It's a Gift
> > > > > >
> >
> > > > > >
> > > >
> > -------------------------------------------------------------------------
> > > > > > This SF.net email is sponsored by: Microsoft
> > > > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> >
> > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > > > _______________________________________________
> >
> > > > > > Mira-development mailing list
> > > > > > Mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > > > >
> > https://lists.sourceforge.net/lists/listinfo/mira-development
> > > > > >
> > > > >
> > > > >
> > -------------------------------------------------------------------------
> > > > > This
> > SF.net email is sponsored by: Microsoft
> > > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >
> > > > > _______________________________________________
> > > > > Mira-development mailing list
> > > > > Mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >
> > > > > https://lists.sourceforge.net/lists/listinfo/mira-development
> > > > >
> > > >
> > > >
> >
> > > >
> > > > --
> > > >
> > > >
> > > > Max Bossino
> > > > Project Manager
> > > > http://miragroupware.org
> > > >
> > -------------------------------------------------------------------------
> >
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > >
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > Mira-development mailing list
> > > >
> > Mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > > https://lists.sourceforge.net/lists/listinfo/mira-development
> > > >
> >
> > > >
> > >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> >
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Mira-development mailing list
> >
> > > Mira-development-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mira-development
> >
> >
> > You keep typing, we keep giving. Download Messenger and join the i'm
> > Initiative now. Join in!
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> >
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Mira-development mailing list
> > Mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >
> > https://lists.sourceforge.net/lists/listinfo/mira-development
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> > Mira-development mailing list
> > Mira-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/mira-development
> >
> > _________________________________________________________________
> > Connect and share in new ways with Windows Live.
> > http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
>
>
> --
> Max Bossino
> Project Manager
> http://miragroupware.org
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Mira-development mailing list
> Mira-development-5NWGOfrQmneRv+LV9MX5uv+2+P5yyue3@public.gmane.orgt
> https://lists.sourceforge.net/lists/listinfo/mira-development

You keep typing, we keep giving. Download Messenger and join the i’m Initiative now. Join in!

Meeting this Sunday

Re: Meeting this Sunday

Re: sync design

Re: sync design

I was thinking the other day that it shouldn't be hard to do a full P2P implementation for LANs.

Basically all we need to do is send a (maybe level 2) multicast message to discover other mira clients in the
LAN. This is probably how groove does it. I've never used groove so I have no clue, but from what I've been
told groove "discovers" other clients in the LAN. Reading through asio's documentation this is pretty
easy to do.

For this we will probably need to implement some type of PKI or something for authentication.

The only things is this brings more complication for the sync problem in the file utility.

I plan on getting the client network code working since no one else seems to want to take the job and might get
this working after getting to talk to the server.
------------------------

Now about xdelta. I haven't had time to fully figure out xdelta. It's a pretty complex system and I just
really don't have time to figure it out. This is probably the main thing the outsourcers will have to work
on. After getting xdelta to work the way we want to, the rest should be easy to implement. To start with they
should get the parts that we need from xdelta and embedded in our code. (xdelta is released under GPL2 so
this should be possible legally). Of course we would give credit for their work.

So (max) when you talk to the outsourcers let them know that their main priority and first task is to embed
xdelta in our code and provide us with an easy-to-use C++ API for it.

More comments are embedded in your email.

Respectfully,

Alan Alvarez
SPC(P), USA

----- Original Message -----
From: J_K9 <aib.wolphin@...>
Date: Friday, December 21, 2007 18:34
Subject: Re: [Mira-development] sync design
To: Mira Development Mailing List <mira-development@...>

> It's almost Christmas so I doubt many of you are going to read 
> this soon,
> but if you do get the chance to then your comments would be greatly
> appreciated! This is a list of everything we've discussed about 
> the sync
> system, which the outsourcer's developer will be working on 
> starting January
> 1st, so I really want to have this document as complete as 
> possible (and
> hopefully make its blueprint before the new year).
> 
> 
> Workplace revisions will be in the form of xdelta
> <http://xdelta.org>differentials or "deltas." A revision may consist
> of one or more deltas,
> depending on the number of Utilities which have been updated in a 
> Workplace.These deltas will be stored in the format 
> "utilityname.rX.xdelta", where
> "utilityname" is the name of the Utility which has been updated 
> and "X" is
> the revision number. The deltas will be stored in the relevant 
> Workplace'sstorage center and will be hidden from the user on the 
> client-side.

hm I'm not sure if we should keep xdelta for each individual file or for the whole repository. We still need to
research more on how xdelta works. I haven't had any time for this. Maybe this is something the outsourcers
will have to figure out on their own.
> 
> The Server will store:
> 
>   - Original File
>   - All the deltas from each revision.
> 
> The Client will store:
> 
>   - Working copy (visible to the user, editable)
>   - All the deltas from the revisions since the least up-to-date 
> Client   last went offline
>   - Latest ("Current") revision.
> 
> For now, we are going to stick to a Client-Server sync system 
> only. However,
> we will implement the elements required to allow the P2P sync 
> system to work
> (e.g. storage of deltas on the Client) without delay so that, in 
> the future,
> we can implement the P2P sync system with greater ease.
> 
> If a member of a Workplace does not connect to the Workplace for a 
> period of
> days as defined by the Workplace's Project Manager, the member 
> will be
> kicked from the Workplace. The files on the Client will not be altered
> despite the member having been removed from the Workplace (for now).

This is something that might have to change if we plan to implement a full P2P implementation with no server
dependance. Look at the top of the mail for more explanation on this.

> 
> When a Client chooses to upload the changes, a file stating which 
> files have
> been altered (and created by the background Mira Daemon which 
> monitors for
> changes made to files in the Workplace directories) will be 
> parsed, those
> paths diff'd by xdelta and those diffs transferred to the Server. 
> <- this
> needs work. Could someone please expand?

Do we need this at all? Actually I'm not really sure what you mean by this. I'm not sure we need a mira daemon
which monitors for changes made to files.

> 
> With regards to the actual network transfer system, how will the 
> data be
> transferred? Also, do we need to add some more communication
> protocols<https://blueprints.launchpad.net/mira/+spec/net-protocols>to
> deal with querying the revision count and other data required for the
> system to function properly?

Yes, We will need to add more stuff to the protocol to set up the transfers and all that.
Also new connections will need to be started for the transfers etc...

> 
> Any comments/criticisms/suggestions will be great - the more solid 
> thisdocument is, the more work the outsourced developer will be 
> able to do next
> month.
> 
> Regards,
> 
> Max Bossino
> Project Manager
> http://miragroupware.org
> 
> On 14/11/2007, Alvarez, Alan SPC MIL USA FORSCOM 
> <alan.alvarez@...>wrote:
> >
> > Well for now we can just keep the stuff in the user's directory 
> because to
> > get synced again all the user would need to do is get the new 
> deltas from
> > the server. We'll what happens later.
> >
> > > The Server might not need to keep a current revision (by which you
> > > mean a
> > > current copy, correct?). I think that'd be an unnecessary
> > > duplication of
> > > data on the Server. As long as it has the Original file and all
> > > the deltas,
> > > it has the latest copy of all the data (except unsynced 
> changes on
> > > Clients).
> >
> > Current copy is more than just a revision. Like I said revision 
> = xdelta
> > file.
> > The reason why I said that we *might* need this is because 
> processing all
> > the deltas might be not be very const-effective depending on how 
> many deltas
> > there are and how big the current version of the file is and how 
> many times
> > the server will need to send a current version of the file to a 
> user (if at
> > all). For now we won't do that. Again, we'll see what happens 
> later on.
> >
> > > Maybe we should have the Server store individual deltas for each
> > > file/Utility and then a 'revision' in a database, where the
> > > revision states
> > > which deltas apply to that update? That would allow users to
> > > revert to
> > > previous versions on a per-file/per-Utility-object basis.
> >
> > We might not really have a need for this. We can name the delta 
> files "
> > filename.r2.xdelta" or something like that. What I meant was if it's
> > really cost-effective to process all the deltas needed to get to 
> a specific
> > revision from the original file. Also, if anyone knows of a 
> better way to do
> > this.
> >
> > Anyways... it seems most of the issues are resolved. I'm really 
> happy> about this :).
> >
> > It'd be really nice if the more experienced people would look 
> over this
> > design and try to improve it.
> >
> > Respectfully,
> >
> > Alan Alvarez
> > SPC(P), USA
> >
> > ----- Original Message -----
> > From: J_K9 <aib.wolphin@...>
> > Date: Wednesday, November 14, 2007 11:05
> > Subject: Re: [Mira-development] sync design
> > To: Mira Development Mailing List <mira-
> development@...>>
> > > On 13/11/2007, Alvarez, Alan SPC MIL USA FORSCOM
> > > <alan.alvarez@...>wrote:
> > > >
> > > >
> > > > hm I think you misunderstood what I said. I didn't suggest we
> > > delete the
> > > > data on a client that has been offline for too long. I was
> > > talking about
> > > > deltas on peers only.
> > > >
> > > > I'm not sure what would the best way to handle users that
> > > haven't sync'ed
> > > > in a long time.
> > >
> > >
> > > Neither am I... Kicking them out of the Workplace seems like a
> > > good idea,
> > > but if we store their working copy and they then rejoin the
> > > Workplace, what
> > > happens? Does the old working copy get moved to a different
> > > directory on the
> > > Client so that they can look at it and copy the changes over to
> > > the new
> > > working copy, or does the Client resync itself with all the 
> deltas and
> > > upload its own changes to that old revision (conflicts will be
> > > likely here)?
> > >
> > > Another thing, no, we don't need to keep the original file on the
> > > user. I
> > > > was still thinking of the first design I had.
> > > >
> > > > So, users will only keep:
> > > > - Deltas (only some of them)
> > > > - Current revision
> > > > - Working copy
> > > >
> > > > Server will keep:
> > > > - Original file
> > > > - All deltas
> > > > - *Maybe* current revision.
> > >
> > >
> > > Ok.
> > >
> > > The Server might not need to keep a current revision (by which you
> > > mean a
> > > current copy, correct?). I think that'd be an unnecessary
> > > duplication of
> > > data on the Server. As long as it has the Original file and all
> > > the deltas,
> > > it has the latest copy of all the data (except unsynced 
> changes on
> > > Clients).
> > > I'm still thinking how to revert back to previous versions.
> > >
> > >
> > > Maybe we should have the Server store individual deltas for each
> > > file/Utility and then a 'revision' in a database, where the
> > > revision states
> > > which deltas apply to that update? That would allow users to
> > > revert to
> > > previous versions on a per-file/per-Utility-object basis.
> > >
> > > --
> > > Max Bossino
> > > Project Manager
> > > http://miragroupware.org
> > >
> >
> > -----------------------------------------------------------------
> --------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a 
> browser.> Download your FREE copy of Splunk now >> 
> http://get.splunk.com/> 
> _______________________________________________> Mira-development 
> mailing list
> > Mira-development@...
> > https://lists.sourceforge.net/lists/listinfo/mira-development
> >
> 

Re: sync design

Re: sync design

Comments embedded in your email.

Respectfully,

Alan Alvarez
SPC(P), USA

----- Original Message -----
From: J_K9 <aib.wolphin@...>
Date: Saturday, December 22, 2007 1:07
Subject: Re: [Mira-development] sync design
To: Mira Development Mailing List <mira-development@...>

> Hi Alan,
> 
> On 21/12/2007, Alvarez, Alan SPC MIL USA FORSCOM 
> <alan.alvarez@...>wrote:
> >
> > I was thinking the other day that it shouldn't be hard to do a 
> full P2P
> > implementation for LANs.
> >
> > Basically all we need to do is send a (maybe level 2) multicast 
> message to
> > discover other mira clients in the LAN. This is probably how 
> groove does it.
> > I've never used groove so I have no clue, but from what I've 
> been told
> > groove "discovers" other clients in the LAN. Reading through asio's
> > documentation this is pretty easy to do.
> >
> > For this we will probably need to implement some type of PKI or 
> something> for authentication.
> >
> > The only things is this brings more complication for the sync 
> problem in
> > the file utility.
> 
> 
> Exactly. That sounds really great, and if it's not too difficult to
> implement then so much the better! However, I still think we 
> should leave it
> for a later release just so that we can get the absolute core 
> working. P2P
> is a great feature (and will be a key part of the system in the 
> future), but
> it is more of an advantageous addition rather than a necessity. 
> For now, we
> should focus on what Mira absolutely needs in order to work.
> 
> Now about xdelta. I haven't had time to fully figure out xdelta. 
> It's a
> > pretty complex system and I just really don't have time to 
> figure it out.
> > This is probably the main thing the outsourcers will have to 
> work on. After
> > getting xdelta to work the way we want to, the rest should be 
> easy to
> > implement. To start with they should get the parts that we need 
> from xdelta
> > and embedded in our code. (xdelta is released under GPL2 so this 
> should be
> > possible legally). Of course we would give credit for their work.
> >
> > So (max) when you talk to the outsourcers let them know that 
> their main
> > priority and first task is to embed xdelta in our code and 
> provide us with
> > an easy-to-use C++ API for it.
> 
> 
> Of course.
> 
> What exactly should I ask them to implement? What I mean is, what 
> functions,as a developer, would you like to be able to access 
> using their xdelta
> wrapper's API?
> 

well that's for them to figure it out since they're going to design/implement it. For now all they need to
know is what we want to accomplish which what we have talked about so far describes it.

> > These deltas will be stored in the format
> > > "utilityname.rX.xdelta", where
> > > "utilityname" is the name of the Utility which has been updated
> > > and "X" is
> > > the revision number. The deltas will be stored in the relevant
> > > Workplace'sstorage center and will be hidden from the user on the
> > > client-side.
> >
> > hm I'm not sure if we should keep xdelta for each individual 
> file or for
> > the whole repository. We still need to research more on how 
> xdelta works. I
> > haven't had any time for this. Maybe this is something the 
> outsourcers will
> > have to figure out on their own.
> 
> 
> Ah, ok. If not we could employ a "filename.utilityname.rX.xdelta" 
> format,where "filename" is the name of the file/element/data 
> section? Xdelta would
> definitely be able to diff that.
> 
The format itself is not really important right now. What I'm thinking is do it more like SVN does it; Have a
couple of meta files/folders.

> > If a member of a Workplace does not connect to the Workplace for a
> > > period of
> > > days as defined by the Workplace's Project Manager, the member
> > > will be
> > > kicked from the Workplace. The files on the Client will not be 
> altered> > despite the member having been removed from the 
> Workplace (for now).
> >
> > This is something that might have to change if we plan to 
> implement a full
> > P2P implementation with no server dependance. Look at the top of 
> the mail
> > for more explanation on this.
> 
> 
> That's ok - it's something we should be able to change with relatively
> little difficulty in the future.
> 
> >
> > > When a Client chooses to upload the changes, a file stating which
> > > files have
> > > been altered (and created by the background Mira Daemon which
> > > monitors for
> > > changes made to files in the Workplace directories) will be
> > > parsed, those
> > > paths diff'd by xdelta and those diffs transferred to the Server.
> > > <- this
> > > needs work. Could someone please expand?
> >
> > Do we need this at all? Actually I'm not really sure what you 
> mean by
> > this. I'm not sure we need a mira daemon which monitors for 
> changes made to
> > files.
> 
> 
> Actually... Now that we're embedding xdelta, we don't really need it.
> 
> Well, what I mean is that how is Mira going to know when a file 
> has been
> changed (and so which files to diff with xdelta)? If Mira is 
> closed, a user
> edits a file on the filesystem manually and then re-opens Mira and 
> choosesto upload their changes, how is Mira going to know that it 
> needs to diff
> that file?
> 
> Originally, we said that a Mira Daemon/Service would monitor the 
> directoriesfor changes and log which files had been altered, 
> because this would cause
> far less CPU overhead than having to grab the MD5 hash of all the 
> files (to
> compare to a previous list of hashes and thus discover which files 
> have been
> modified) when the user chooses to upload their changes.
> 
> How do you propose Mira Client detects modified/new files to diff them
> otherwise? Also, when diff'ing a file (with xdelta), isn't a 
> reference file
> needed to know what exactly has changed since the last time it was 
> diff'd? A
> Current Copy, of sorts? But then, that would duplicate the amount 
> of data on
> the client-side, which is another problem altogether...

I think we already went over this. We're keeping a current copy of the file. Yes it's a bit more of space, but I
think it pays off. This is also a lot simpler to do for now. Maybe we could implement this in the future if we
think we need it.

> 
> Any ideas?
> 
> Yes, We will need to add more stuff to the protocol to set up the 
> transfers> and all that.
> > Also new connections will need to be started for the transfers 
> etc...
> 
> Ok.
> 
> Regards,
> 
> Max Bossino
> Project Manager
> http://miragroupware.org
> 

Re: sync design

Re: sync design

comments embedded

and one more thing. I think it's been over a month since you sent out that email regarding people not
contributing to the project.
I'm really losing interest in this project as time goes by and you and I are the only ones that seem interested
in contributing.

Though people have said they have interest in the project, and they keep saying that "next weekend" is going
to be the day they're going to work on something, we haven't accomplished anything at all. The svn
repository has been set up for many months now and there's barely any code in it.

The reason why I joined this project and quit working on my previous one was because I wanted to work with
other people and so far it doesn't seem like I'm doing that.

If I were (max) you I'd reconsider investing so much money on the outsourcers because when they are done and
gone, I don't see why it wouldn't go back to the way it is right now.

Just wanted express the way I feel about all this :) Hope everybody enjoys their holidays.

Respectfully,

Alan Alvarez
SPC(P), USA

----- Original Message -----
From: J_K9 <aib.wolphin@...>
Date: Saturday, December 22, 2007 13:11
Subject: Re: [Mira-development] sync design
To: Mira Development Mailing List <mira-development@...>

> Comments embedded.
> 
> On 22/12/2007, Alvarez, Alan SPC MIL USA FORSCOM 
> <alan.alvarez@...>wrote:
> >
> > >
> > > What exactly should I ask them to implement? What I mean is, what
> > > functions,as a developer, would you like to be able to access
> > > using their xdelta
> > > wrapper's API?
> > >
> >
> > well that's for them to figure it out since they're going to
> > design/implement it. For now all they need to know is what we 
> want to
> > accomplish which what we have talked about so far describes it.
> 
> 
> Sure.
> 
> >
> > > Ah, ok. If not we could employ a "filename.utilityname.rX.xdelta"
> > > format,where "filename" is the name of the file/element/data
> > > section? Xdelta would
> > > definitely be able to diff that.
> > >
> > The format itself is not really important right now. What I'm 
> thinking is
> > do it more like SVN does it; Have a couple of meta files/folders.
> 
> 
> That's not a bad idea... But that would involve basically 
> reimplementing SVN
> ourselves but using xdelta, wouldn't it?

hm not really. That's just one small detail. Most VCS do it this way, not only svn. I was using svn it's widely
known and is what we're using.

> 
> And if that's the case, once the outsourcer has embedded xdelta 
> should he
> read up on SVN and implement it in the Storage Layer?
> 

not necessarily. This is some I proposed before but I'm not sure how much of svn we'de be able to use. Someone
would have to look into this.

> >
> > > How do you propose Mira Client detects modified/new files to 
> diff them
> > > otherwise? Also, when diff'ing a file (with xdelta), isn't a
> > > reference file
> > > needed to know what exactly has changed since the last time it was
> > > diff'd? A
> > > Current Copy, of sorts? But then, that would duplicate the amount
> > > of data on
> > > the client-side, which is another problem altogether...
> >
> > I think we already went over this. We're keeping a current copy 
> of the
> > file. Yes it's a bit more of space, but I think it pays off. 
> This is also a
> > lot simpler to do for now. Maybe we could implement this in the 
> future if we
> > think we need it.
> 
> 
> I don't think we ever agreed on this though. Perhaps we could 
> follow the
> "re-implement SVN with xdelta" method, which would avoid having to 
> keep a
> Current Copy on the Client and also cater for our synchronisation 
> needs?
> If we were to go down that road.. Would it be faster to embed SVN 
> or make
> our own version which does only what we need for revision control and
> synchronisation?

hm I don't know if you know this or not, but svn DOES keep a current copy and a working copy of files.
Keeping a current copy allows for faster diffs and less bandwidth usage. This is VERY usable for people with
slow connections.
bandwidth is a bit more expensive than hard drives these days. That's just my opinion.

> 
> Regards,
> 
> Max Bossino
> Project Manager
> http://miragroupware.org
>