Closed Bug 124026 Opened 23 years ago Closed 20 years ago

Roaming - funding via Beonex

Categories

(Core Graveyard :: Tracking, enhancement)

Product:
Core Graveyard
Component:
Tracking
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: BenB, Assigned: BenB)

References

(
URL
)

Details

(Whiteboard: 3250$ for bug 124029 + 350$ general so far) 

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.
QA Contact: chofmann → ben.bucksch
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.
Blocks: 4xRoaming
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.
Status: NEW → ASSIGNED
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.
Depends on: 124048
No longer depends on: 124048
Blocks: 124048
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.
Whiteboard: 1400$ for bug 124029 so far
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.
Whiteboard: 1400$ for bug 124029 so far → 1400$ for bug 124029 + 200$ general so far
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.
Target Milestone: --- → mozilla1.1
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
Whiteboard: 1400$ for bug 124029 + 200$ general so far → 3250$ for bug 124029 + 350$ general so far
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
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.