331416 - Move toolkit/components/gnome somewhere else

Status: RESOLVED FIXED

(mozilla.org :: CVS: Copy, task, P1)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

toolkit/components/gnome should not be part of toolkit. It doesn't depend on toolkit at all, and it's quite generic. In particular I want to make my system-proxy patch use it, and my system-proxy patch is app-agnostic.

The question is where to move it. The most obvious place is extensions/gnome. We already have extensions/gnomevfs.

Brian, what do you think?

Comment 1

[Brian Ryner (not reading)]

sure, any place is fine.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: cvsmoves

I decided on extensions/gnomeservices. ("extensions/gnome" wasn't good because having one extension name be a substring of another extension name breaks things.) The IDL files can't go in extensions/gnomeservices because they need to be accessible whenever GTK2 is built, even if the gnomeservices component isn't built. So I put them in widget/src/gtk2.

So here is a list of CVS copies to be made.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

preed, are you doing CVS repository copies these days?

Comment 4

[Benjamin Smedberg]

Ugh, why extensions/ ? I've been trying to move code out of extensions that wasn't actually going to be an extension.

Where does the system-proxy code live?

Or, to start over, why is toolkit/ a bad place for this code? toolkit/ is app-agnostic, and we already build parts of it for seamonkey etc.

Comment 5

[Darin Fisher]

bsmedberg: Then where should optional toolkit components live?  Right now, mozilla/extensions seems to be the best place.

roc: I think that extensions/gnomevfs could be merged with the stuff in toolkit/components/gnome.

Comment 6

[Benjamin Smedberg]

What does "optional" mean?

Comment 7

[Darin Fisher]

I was referring to 'optional' from the point-of-view of applications bundling the toolkit.  We have many optional components in toolkit today, and the various apps pick-n-choose components that they wish to bundle.  Obviously, some (or all) of that goes away when those apps target xulrunner.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> Where does the system-proxy code live?

My current patch has it in toolkit/components/unixproxy, but I was going to move it to extensions/unixproxy. It depends only on the gnome service and netwerk. I've always thought of toolkit as components for XUL applications, and this is a lot lower-level than that.

However I'm happy to close this bug as WONTFIX and land my original patch. Please decide amongst yourselves.

Comment 9

[Benjamin Smedberg]

Toolkit is not just for XUL apps nowadays, so I'd vote to WONTFIX this.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> I've been trying to move code out of extensions that wasn't actually going to
> be an extension

If we go down this path, then toolkit is going to become one big grab-bag of independent modules and collect a lot of what's in extensions/ today. Looking at extensions/, these look like candidates for toolkit/:

auth
cookie
gnomevfs
help
manticore
mono
permissions
pref
python
schema-validation
spellcheck
sql
tridentprofile
typeaheadfind
sroaming
universalchardet
wallet
webdav
webservices
xmlextras
xml-rpc

Is that going to be OK?

I'm a bit concerned that modules which are extensions today might not be extensions in the future, and vice versa, and it would be nice to not have to move them around the tree to keep things consistent.

Comment 11

[Benjamin Smedberg]

There are better places for some of these directories

> auth

netwerk/auth?

> gnomevfs

netwerk/ ?

> help

replaced by toolkit help viewer

> pref

modules/libpref

> typeaheadfind

Replaced by toolkit TAF

> universalchardet

intl/universalchardet

> webdav
> webservices
> xmlextras
> xml-rpc

All belong in content/... and several are built in tier 9 already.

> I'm a bit concerned that modules which are extensions today might not be
> extensions in the future, and vice versa, and it would be nice to not have to
> move them around the tree to keep things consistent.

Absolutely. I'm of the opinion that we ought not check anything in under extensions/, instead finding or creating an appropriate module for it. And I have most of the build-config goop in place already to make that possible.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Given those decisions, then the proper place for unixproxy would seem to be netwerk/, but having a netwerk component depend on gnomeservice in toolkit/ doesn't seem good.

I guess this particular problem is that we need somewhere to put GNOME platform stuff that's really below both netwerk/ and toolkit/. The closest we have is widget/, but that doesn't seem quite right.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I've also got a dbus component that depends on nothing, implements a netwerk/ interface, but might be extended to implement other non-netwerk stuff.

My opinion is hardening that extensions/ is the right place for gnomeservice and dbus. These are optional components that are not needed for Gecko products to function, and they are not strongly associated with another Gecko module. Other Gecko modules need not explicitly depend on them as long as the interfaces they implement live elsewhere.

On the other hand, I think it would be reasonable to put unixproxy in netwerk/system/unixproxy. There is still the question of where to put nsIGConfService.idl so that we can access it from netwerk without creating horrid dependencies. My current best idea is to create a new directory xpcom/system for platform-specific, low-level interfaces (not implementations) to components exposing system services. mkaply, would that have served your OS/2 WPS needs?

Comment 14

[Mike Kaply [:mkaply]]

yeah, that would work. We've actually created a service for this stuff with IDL and the works...

Comment 15

[Darin Fisher]

I'm not sure about netwerk/system and xpcom/system yet.  Let's get a discussion going in dev-platform :)

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A decision has been reached. The IDL is going to xpcom/system. The actual component is going to toolkit/system/gnome.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: updated cvsmoves

This is the updated cvsmoves file. These moves can go ahead. Note that the directories toolkit/system and xpcom/system don't currently exist and may need to be created in the repository.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I do wonder why it's called 'cvsmoves' when we really want copies.

Comment 19

[J. Paul Reed [:preed]]

ETA on some action on these is 4/28.

Comment 20

[J. Paul Reed [:preed]]

Justdave will take care of these cvs moves during the scheduled CVS server outage the evening of 4 May.

Comment 21

[Dave Miller [:justdave]]

pre-flight sanity check says:

destination directory toolkit/system does not exist, will be created
destination directory xpcom/system does not exist, will be created

If that's a problem you've got about 15 minutes to say so before I make it happen.

Comment 22

[Dave Miller [:justdave]]

Attachment: cvscopy transcript

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks, that's good.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Argh. I stuffed it up.

Those files should have landed in toolkit/system/gnome, not toolkit/system. My script in comment #2 was wrong.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: move files to their correct location

very, very sorry :-(

Comment 26

[Dave Miller [:justdave]]

I'm aiming to hit all these this weekend at some point while everything's offline anyway.

Comment 27

[Dave Miller [:justdave]]

Attachment: cvscopy transcript