This is a tracking bug for funding development of roaming capabilities (bug 17048) through Beonex. (I excuse for using bugzilla.mozilla.org for that, but we don't have a bugzilla running at Beonex yet. If anybody from staff@mozilla.org has objections, feel free to close this as INVALID and I'll look for another forum.) This is a meta-bug for all interesting in the funding ofo this general feature. As pointed out, the defintion is much too broad still to start this type of funding. People have different needs. I will file new bugs for more concrete suggestions, and you can do so as well. Some of them might be functionally subsets of others. Then you tell me, what you would donate your money for. There are several decisions to make, some of which greatly influence the architecture of the implementation: - Should Mozilla sync during runtime or on startup/shutdown only? - Client/server protocol used, e.g. - HTTP PUT/MOVE - WebDAV - ACAP I'll dig into my archive about the technical discussion for more questions. In any case, we could agree on a trustee, who decides, if the requirements have been met (e.g. the mozilla.org module owner who does the review) and another one that keeps the money in a safe place until Beonex (which probably means me) meets the requirements. Not sure, if that's necessary, though (you tell me), since it's (time- and money-costly) overhead. A big thanks to Matt Perry who made this possible! He is the first person who ever offered more than a pocket money for such a thing to Beonex. There's a threshold before any action makes sense, and he got us over it.

Sync during runtime is very important to me. I don't want to have to start and stop the browser all of the time. (Bug #78072 may feature in this -- making mozilla responsive to changes in the bookmarks file on the fly (and making it write out the file whenever a change is made) would be a quick way to let people implement this sort of functionality external to the program with hacked-up scripts. But, if Mozilla can sync every n minutes itself, that's suddenly not very interesting.) Note that the original 4.x code didn't really "sync" in any way -- it just copied the file it thought was newer back and forth, and it sometimes made mistakes and lost data. I really want true syncing -- see bug #17917. I'm only able to offer pocket money in either case, but more pocket money for the more complete syncronisation ability. :) As for protocol: http put/move is adequate for the simple "copy the whole file around" bit, but something like ACAP seems necessarly for the more sophisticated version.

Matthew Miller, yes, sync during runtime is definitely better, but also by an order of magnitude more complicated (meaning that much more funding is needed). As you said, we need support for that in the data-specific code (e.g. bookmarks-, cookies-, address book- etc. code) and HTTP might not suffice either anymore. OTOH, I guess, many people just want the profile to follow them as they move machines, and never use 2 machines at the same time, so bug 124029 might suffice for them. If you mail me your money offers, please describe at least vaguely, what you want implemented minimally. If you want to devide your money like Matthew Miller (e.g. 50$ for bug 124029 and another 50$, if we can sync during runtime), you can do that as well. You get what you pay for and pay for what you get ;-P.

I think we need separate paypals! Yes, make it more complex! one paypal for each bug that branches from this one. My fistful of dollars are on: - "Exactly like NS 4.79 - Put/MOVE, Simpleput, HTTP only" .. but that's just because I don't give a whit about the rude LDAP implementation NS4 has. Lump me in with the NS4-incl-rude-LDAP if granularity requires. Show me the paypal, my visa's burning a hole in my pocket. Yeah. We better get a Thanks Page together, too, and make Matt famous/notorious. I've only barely making the buy-in, because I'm, as I told Ben, a cheap, cynical bastard. - bish

My abolsute bare-minimum requirements are that it work with Apache's mod_roaming. It doesn't have to be pretty and I don't need LDAP support. It just has to upload and download my preferences (including browser config, mail settings (but not mail itself), and bookmarks) -- basically everything that 4.x does now. Sounds close enough to bug 124029. Having said that, I would like for it to be modular enough that we can expand it easily. That way someone can come along and write a LDAP, HTTPS, ACAP or whatever module that can be added in without having to rewrite all of the roaming code. We could also go ahead and put an option to call an external program for syncing and let people write their own external files for handling a syncing method that's not yet supported in the core code. I don't care if it syncs at start up and shutdown or during the browser session. If I'd have to pick one I would choose on startup and shutdown as that works fine for me now. Maybe we could make it an option which one you want if they both get implemented.

Rather than having separate paypal accounts, I'd rather see a progressive scale of what gets done given what amount of money, a la the goats comic strip http://www.goats.com/ -- if they get $750, they run a color strip the next month, if they get more than that, they do other things. Something like $ add simple http-based startup/shutdown roaming bookmarks $$ add the same functionality for cookies, etc. $$$ make it work at intervals in the background while running $$$$ add the ability to really sync -- probably add acap support $$$$$ add enterprise-level ldap support With the $ figures above filled in by ben with real numbers.

oooh, and put https on the chart somewhere too. almost forgot that. (aside -- should bug #17917 be set as blocked by this, or should a more specific bug be created?)

Matthew Miller, I don't think that will work, because the requirement don't add that nicely - some are "orthogonal", i.e. you can have none, either one or both. I filed bug 124048 for sync during runtime.

> Having said that, I would like for it to be modular enough that we can > expand it easily. That way someone can come along and write a LDAP, > HTTPS, ACAP or whatever module that can be added in without having to > rewrite all of the roaming code. Sure, I think that's easy enough that I consider it a must for any good code. OTOH, sync during runtime is so different from sync during startup that the implementations would probably share almost no code.

Ben -- hmmm, they seem basically cumulative to me. The case where they aren't might be the leap from copying whole files to actually syncing individual bookmarks, etc. within those files, but there, even though the code might be separate, the first is conceptually (to a user, and perhaps more importantly to potential donors) a first step towards the second. Once the second (order of magnitude harder) problem has been solved, the first can still remain as a legacy mode.

I want to be clear on terminology. Perhaps can we use "sync" for actually syncronizing individual items, and "copy-newer" for NS 4.7x like functionality? (Anyone have a better word?)

By request, I created a PayPal account. (After being through with the Terms Of Use - that must be the longest ToU I ever saw, and not unproblematic either. Oh well...) You can start sending money via PayPal already, if you want. Fields should be filled out that way: Recipient's Email: paypal@beonex.com Type: Service Subject: Enter the bug number of the bug you want to fund, e.g. "bug 124029" or "bug 124026", if you don't care about the implementation/capabilities. Note: Please add a password here, so I can securely identify you during further email communication. If you have any further requirements, please add them here. If anything is of special importance to you (even if already noted in the bug), please add that here, too. I might create a nice form on my website, once (if?) I figured it all out. I think you have to sign up to PayPal to pay to the PayPal account, no matter, if you use a credit card or back account :-(. If you sign up to PayPal, please use this URL: <https://www.paypal.com/affil/pal=paypal%40beonex.com>. More info: <https://www.paypal.com/cgi-bin/webscr?cmd=p/gen/referral-faq>. Please do not send money for bug 124048 yet, because it doesn't look like there'll be enough money for it. Feel free to mail me your intend, though. >500: If you want to send 500$ or more, please contact me before sending any money. 50-500: I will try to get at least bug 124029 done, but I cannot promise anything yet. If I fail to deliver, we will talk. I can then refund you the money, if you wish. <50: You may send less than 50$, but I will take it as general donation for Mozilla development (non-refundable) and you cannot influence development other than the wish you noted during sending the money. The communication overhead would be far too high otherwise - sorry. In any case, please refrain from paying by credit card and then charging back the payment via your credit card company, because that will cost me real money. I am new to PayPal and to the whole donation development model, so please bear with me. Suggestions are welcome.

Ben -- actually, you might be better off with Amazon's tip jar system http://s1.amazon.com/exec/varzea/subst/fx/home.html/ref%3Dgw%5Fhp%5Fls%5F1%5F4 I think they charge less of a fee than PayPal does, and you just need a credit card to donate. And I *really* think you should consider the "goal thermometer" approach I suggested above. :)

Ben, A couple questions. 1) Before I blindly send money, I like to know something about who's getting it. Where can we find more info on you, what your qualifications are to do this work, etc. Would be nice if these items could be posted directly to this bug, so anybody else who wants to donate already sees answers. 2) I thought you said that a "trusted 3rd party" would be accepting the money on your behalf. Do you see a potential conflict of interest if the developer receives the money before the work is done? What if we disagree that the work is complete? Surely this must have been dealt with previously. I obviously mean no slight against you with these questions. It's simply that I don't personally know you. - Adam

Adam Masri, 1) what I did before: Search bugzilla for <mozilla@bucksch.org> and <ben.bucksch@beonex.com>. Be sure to include open and fixed bugs. Maybe also search LXR for "Bucksch". If you care, you may also read the newgroups, esp. .mail-news. I also created Beonex <http://www.beonex.com> (Beonex Communicator is currently dormant :-( ). 2) Trustee: Money holding: I thought about sourcexchange.com, but it seems they're gone. I don't know any service doing that, with reasonable fees. As for when the work is done, that's more easy. We could pinpoint any trusted (by both sides) third-party involved with mozilla.org, e.g. the Profile Manager backend module owner (not sure, who that is currently). He decides, if I fixed this bug.

I'll donate $100 toward development of this feature, plus considerable time QA'ing any resulting patches. Personal preference would be to have this feature abstracted from underlying transports, so either HTTPS, LDAP or ACAP would be used. This feature would go a very, very long way toward corporate acceptance of Mozilla in its network .. the audience here is corporate IT management. (For what it's worth, a major government research laboratory in the east Bay Area wants an ACAP-based system for storing address books, et al. Exactly the point of this feature. Netscape 4.x's growing too long in the tooth to maintain.) Regards, Jubal Kessler

Ben -- can we have an update on how it's going? Both funds raised and actual progress? thanks!!!

Matthew: Progress: None recently, because this won't get into 1.0 anyways and I have some things I want to get in there, and a Beonex Communicator release to do. I did speak with Conrad Carlen, maintainer of the profile code (I think), and he have me a few very helpful hints for the implementation. Funds: Status Whiteboard updated.

When I see the neverending discussions about "what protocol to use" I can't stop thinking.... WHY NOT FTP? Advantages of ftp: - It is an existing protocol in the Mozilla/Netscape network i/o engine - The server would be VERY easy to implement. Just use any ftp server. - Corporate Firewalls normally have ftp access enabled (inbound and outbound) - Most corporations already have an ftp server already in place. - It would be a matter of adding a checkbox and entry field in the "Profile Manager" dialog, labeled as "Use remote profile []" and an entry field for the "ftp://user:pass@host" url. Mozilla would just create a subdir on the systems temp dir, copy the files from the ftp server, and when the browser is closed (or "after x mins" as set in the Advanced->Remote profiles preferences) the data would be uploaded back to the ftp server, and at program exit that temp data would be erased (for security reasons). Why not doing it this way? Having _something_ that does the job and is based on existing, trusted protocols, is better than having nothing (current situation), or something fancy and elaborate, that takes months to complete. Anyone has any comments on this ftp:// aproach and why it shouldn't be done this way (at least as a starting point). Just my $.02.

That discussion doesn't really belong in this bug.

> Anyone has any comments on this ftp:// aproach and why it shouldn't be done this > way See my response on bug 17048

Fernando Cassia, please do not comment here, unless you are willing to donate money. And in general, please don't add your comments twice. We've already read that in the other bug. > - It is an existing protocol in the Mozilla/Netscape network i/o engine No, it isn't. There is no FTP upload implemented, to my knowledge. > better than ... something fancy and elaborate, that takes months to complete. See bug 124029.

It's the only thing that got me to switch from 3.x to 4.x and it is the only thing keeping from adopting mozilla. Some things I've mentioned before, elsewhere, and don't see here: Send diff's over the wire. Keep a copy of the virgin download and diff against what you are about to upload, if the resulting diff is smaller, send that instead. Support for romaing over https. Support for content-encoding. It would be lovely to apply some gzip chain on the server to make the downloading of a large bookmark file (esp over a dialup) quicker. This one should be really easy it would seem as the core already supports content-encoding.

Ben, what sum is enough for closing the bug #124029 ? -- is it $1400 or you need more? is the feature still scheduled for 1.1alpha -- that's a month or two from today, according to http://www.mozilla.org/roadmap.html ? Lack of NS4+-like roaming is _the_only_ thing that prevents me from dropping NS in favor of Mozilla right now.

I think we have enough money - I had another big donnation promised (I have to look into the details there, so I didn't add it yet). When Beonex Communicator 0.8-pre is released, I'll start working on bug 124029. I have another assignment mid of May, though, so I hope that I can finish it until then, but I don't know, if that works. Oh, and please reserve this bug to people who donnated money. That's the whole point of it.

s/donnated/donnate/

Ben, Would it be very much trouble to give us updates on a regular basis so that people won't have to say "what's going on?" every few weeks? I don't even mind if the development takes a bit longer than planned, but I would like to follow this as it goes. Would you mind committing to post an update bi-weekly or monthly? I think it would make everyone who has money on this a little less nervous, even if it's just to say "nothing's been done on this in the last couple weeks because of x".

Yes, I can do that. I thought that I made clear that I don't plan to work on this before Mozilla 1.0 is being released, but re-reading my comment, I didn't. Plans changed, because I didn't know about RC1. Anyways, the current plan is: - get Beonex Communicator released (no later than early next week, hopefully) - then work on bug 124029. - mid of May, I have another assignment, so I'll probably have to stop working on bug 124029. I will try to finish it until then, but I don't know, if I can. I will post what I have (the patch, current state of work) in any case. - if I have time, I will continue to work on bug 124029 in my free time during the assignment, but I doubt it (it might be stressy enough anyways) - the assignment is for 3-5 months (i.e. until mid aug - mid oct). If I didn't manage to finish it earlier, I plan to finish work on bug 124029 directly after that.

> - get Beonex Communicator released (no later than early next week, hopefully) done. I plan to start working on Roaming tomorrow.

Adding the 2000$ of Dave Caplinger (thanks!) Making other donation status adjustments between 124029/general

Sorry for the spam, but has anything been done on this bug?

I believe we need some other programmer to get the money, if ben cannot work on this.

I can and do work on this. Please look at bug 124026. > I believe we need some other programmer to get the money "we"? I wanted to offer you to refund your money, if you are unsatisfied, but my records show that you neither paid nor offered to pay.

Ouch... Look who's here! I'm sorry, but: 1) under "we" I meant the community and the interested people funded. 2) I need this feature, but not so much as others do. I would like to store a remoute profile, but do not need it immediatelly. 3) this bug is 8 months old and you have proprietareted (sorry, do not know how to speak it out on english). And we have no ETA. If I invest mobey I want to know when I get my software... I really dunno why poeple funding this bug do not want clear ETA... Sorry, but that's my opinion - can't work, give it to some other.

As someone who's contributing $1,000 for this to be implemented, I would like to state that I'm not worried about the length of time that it's taking. Ben and I have already chatted some and I've told him as much. I'd rather he work on it and get it done right than rush it out. Besides, you have to put things into perspective. There's only been $3,600 that has been contributed so far. That's not a lot of money for implementing this feature. Ben's got to pay the bills and put food on the table in the meantime, so he's not going to be able to commit every waking moment to working on this. If the contributed amount was $15,000 then Ben might have able to work on this full-time. The reason that he's placed the code under a proprietary license is that he hasn't been paid for his work yet. Once he's done and has been paid then it'll be put under the MPL so that it can be merged into the tree. Other than that, if you don't want to sound like a troll, you're free to either contribute towards getting this implemented so that you have more of a say, or you can simply implement it yourself. After all, you get what _you_ pay for.

Since I am the one originally responsible for this unpleasant discussion, I want to clarify that I was only asking about the state of this bug. I wasn't implying anything. I was just curious what has been done on this bug and when we can expect results.

Thanks very much Matt for your kind words. :-) Yes, for 3600$, with usual rates (mine of of those comparable companies I know), you usually get about a week worth of work. This feature certainly takes a lot longer than that. Please consider that when judging about my performance. That said, I am myself very unhappy that I am working so sporadically on this. I want this to be finished soon. I plan to be done no later than the end of the year, if that helps anybody. (I think I said so before anywhere.) I cannot give good judgements or ETAs, because I cannot predict what happens outside this project and I also have no idea how time-intensive the solutions (and the finding of solutions) for the remaining problems are. For technical status/progress reports, please refer to bug 124029 (which I tried to cite in my last comment, but made a typo). As for the license, the code is under the MPL/LGPL dual license as of now. I recieved legally binding contracts from both Dave Caplinger and Matt Perry, which hopefully is enough legal protection for me. Anybody who did not donate, please see the last sentence of comment 24. I don't want this bug to turn into the mess that is bug 17048.

<http://www.beonex.com/about/contributing> FYI: look at bug 124029 for progress.

That is almost guaranteed *not* to be found there (even if someone were looking for it (like me). "Contributing" should be on the home page, and not under "About". BTW, I just donated €10. (for Title-Tips and PW Profiles) ;)

So, what's the status now? You've got a bunch of patches pretty ready to implement, but we still don't have a real working system yet. Can you give us an ETA, or tell us what you're working on now? - Adam

There *is* a real, working system linked in the other bug.

Sorry, what I meant was, what is the procedure for getting this implemented in Mozilla.org's builds, i.e. not an installed package? What I've noticed is that without serious dilligence by the package author, future builds of Mozilla are likely to break the system you've designed. It would be nice to see this implemented in Moz directly so we don't have to worry about this possibility. Is there a procedure for lobbying to get this implemented as a feature? I would think they would want this feature. - Adam

Yes, I plan to get this into Mozilla, assuming it gets accepted. But that takes time, and nothing stops you from using the builds I created in the meantime.

Well, nothing stops you assuming you're running Linux, which is the only build you link to.

I can produce a Windows build as well later.

I'm on MacOS X. Not sure where that leaves me...

When it's done, there will probably be a Beonex Communicator release with roaming, and there will probably be a Mac OS X version of it.

Matt just transferred me the $1000 he promised. Thanks a lot, Matt!

Marking fixed, because 124029 is fixed and 124048 didn't generate enough interested in terms of $. Those who promised to donate but didn't yet (esp. Bob Zimbinski, Jubal Kessler and possibly others), please do so. See <http://www.beonex.com/about/contributing>. To all the others: Thanks again. Although this bug was a disaster for me personally, and I completely failed with my original intends and promises to have this completed at least end of 2002 (sorry!), I guess it was a learning experience for all of us. I was seeing donations as the future of open-source driven by users, but it seems it doesn't work that way, at least not here. :-( Greetings, Ben Bucksch