Re: Kommander news and fund raising

On Tuesday 26 February 2008 2:45:43 pm Mark A. Taff wrote:
> On Tuesday 26 February 2008 14:17:25 Eric Laffoon wrote:
> > I'm assuming both of these functions automate, but one argument against
> > an FTP function is what if you have shut down FTP on your sever for
> > security reasons. Ideally I would use KIO to match what is in the
> > project, but I'm not sure we exposed this in QuantaIf for number one, and
> > I need to plug it into something like a KDE file widget for number two...
> > That means possibly patching Quanta and and creating a new plugin widget.
> > Also anything that automates syncronization removes my ability to offer a
> > "de-cruft" option to clean up the site, as well as manually select what
> > you want to bring down. There may be settings files you don't want
> > download. It's possible a project manager may want to protect and
> > categorize too, which is not possible without control.
> >
> > It's fairly easy to do this with the HTTP plugin, and possibly it could
> > also be done with a remote ssh shell, though I'd have to ponder how to do
> > it. Anyway the idea is to have something useful for more than just one
> > protocol. Using the PHP backend it would not matter what your protocol
> > was as long as you had PHP on your server, which almost everyone does.
> > It's not perfect, but it's my best idea so far.
>
> What I meant was to say was to literally copy the source code for the rsync
> algorithm from either rsync or lftp.  Then use the KIO-slave spec'd in the
> project to handle the connection between the client and the server.

Gee mark, I wish I could live in that world... Unfortunately I wouldn't be 
doing that in Kommander as a quick project, but in C++ and it woud be 
grueling. As I said in my last email, I cannot directly detect the protocol, 
but I guess I could parse the project file for it. Even so, I cannot use KIO 
to my knowledge in text mode, which would make it all work rather nicely. Of 
course if someone knows something I don't please enlighten me.
>
> Both rsync and lftp allow for tree-trimming.  Quanta could handle it by
> using a .cvsignore file.  In fact, there could be multiple files.
> Think 'de-cruft.cvsignore' or 'default.cvsignore'
> or 'myprojectcustom.cvsignore'.  That would be quite useful, especially if
> you could cascade them, much like CSS, or even just include them.
>
> The rsync algorithm is beautifully bandwidth friendly, which would be quite
> handy for larger projects.  My own website for example, has over 1GiB of
> photos on it.

Bandwidth is irrelevent here. We're taking two file listings, comparing and 
offering users options for differences. The *only* thing coming down the pipe 
is listings and commands until an actual transfer is initiated. At that time 
we're using HTTP which often uses it's own compression or we can expressly 
compress the stream if we want, but I doubt that would be an issue in most 
cases.
>
> So, server <==> KIO <==> .cvsignore filters <==> rsync algorithm <==>
> client

I know this seems conceptually easy, but it amounts to a new KIO slave with a 
rewrite for rsync. I don't even know what it's written in, but I can already 
tell you my experience with many libraries is the initial challenge is an 
interface you can live with or a rewrite, and this isn't even really a 
library. Then on top of all this is the interface. Given I'm not that good at 
C++ this is a month or two I don't have compared to a couple nights with 
Kommander.

Given what you're looking at for bandwidth issues I'd strongly recommend 
Subversion. It's extremely bandwidth friendly. It will get only the changes 
in files, will handle revision control, enable viewing revisions as an atomic 
commit and coordinate multiple users with conflict resolution. It's also not 
hard to set up. Keep in mind anything for merely syncronizing files is really 
a compromise in lieu of a better solution. I use SVN on my sites and local 
projects. Offering this additional tool is worth doing for me only if it is 
marginal effort or someone wants to fund it as a sponsored task to suppor the 
project. That said, I hope to come up with something people like that is 
useful.
>
> > Best of luck to you. You've been a solid supporter over the years and I'd
> > like to think someone of your character would be in demand by astute
> > employers.
>
> Thanks Eric.  I'm going to college full-time now for aerospace engineering.
> It may be some time before I can give money again, but I plan to help out
> with code as time permits.

Whatever works for you is great with me.
>
> The first itch to scratch would be type-ahead-filter for the projects &
> files panes.  That would really make my life easier.

Keep in mind that the 3x series is being replaced and in the 4x series we have 
lots of work done on KDevelop to leverage as well as a better platform. We 
also have more experience and we get to set our own release schedule so we 
should be able to get what we want done instead of shutting off everything 
that takes some time for feature freezes based on desktop schedules. 
>
> Regards,
>
> Mark

-- 
Eric Laffoon
Project Lead - kdewebdev module