>
>
>
>  - it seems inevitable that both gnome-http-lib and Firefox would need
>    to rely on some type of common "repository" of cookies, etc. and that
>    this repo would be managed by some type of daemon that handled
>    locking and change-notification; said daemon would need to be able
>    to run sans Firefox, and would need to handle changes to the repo,
>    not be read-only.


Isnt there some work been done on using gnome-keyring to store
authentication information for firefox? (sorry I cant remember the link to
the patch in FF bugzilla). Wouldnt it be a natural extension to this to use
either use this, or upcoming GSettings (gnome-y) or dconf (more cross
desktoppy) for the cookie store. Both of these implementations already deal
with locking and change notification, so why do we need a new daemon?
(especialy if dconf AIUI is daemonless)

- though it never pays to block on a committee, I would say key
>    people to get "sign off" from (or at least keep informed) would
>    be Alex so we know the solution works for gvfs, and the Mozilla
>    team, so we know they will take the patches to Firefox and
>    be OK with the way it's done


Yeah, and lets not forget webkit also. I think this is where something like
dconf, which sounds a bit less GNOME-y has a greater chance of being signed
off by on multiple projects with stakeholders outside GNOME.

I guess it would then be a natural extension to make libsoup / gvfs et. al
depend on dconf for authentication info and cookies.

But does this then fall down or come back the the same debate about hard and
soft deps and where (how low) something in the stack like dconf,
gnome-keyring and gvfs (authentication) lies.

John


>
>  - the Mozilla team might be interested in this problem on Windows
>    also, since right now using the Windows HTTP stuff shares state
>    with IE, but I'm guessing apps that rely on this get hosed when
>    people use Firefox. So maybe Mozilla would like to provide an
>    HTTP lib on Windows that shares state with Firefox, or something.
>    No idea though.
>
> Havoc
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to