98753 - Move finger, datetime to extensions

Status: VERIFIED FIXED

(Core :: Networking, defect, P5)

Description

[Bradley Baetz (:bbaetz)]

Most people don't need these. Bryner's suggestion was to just move them to
extensions, so people who want them can build it (or --with-extensions=all).

extensions/protocols/*, maybe? (Does our extensions Makefile foo handle that on
all platforms?)

These would be off by default then, so that they don't bloat up the default
build.

Comments?

Comment 1

[Doug Turner (:dougt)]

don't like moving them to extensions.  I would rather see necko have a build 
directive which indicates which protocols should be compiled.

Comment 2

[Bradley Baetz (:bbaetz)]

well, we don't compile without http, I'd guess (all the proxy stuff). Why not
use extentions? All the makefile stuff is then done for us. Its the natural
place, really.

Comment 3

[Darin Fisher]

the core protocols are:

  file
  http
  jar
  res
  about
  viewsource

but most users probably also expect:

  ftp

whereas i suspect the following are unused by most users:

  gopher
  finger
  datetime

and then what about these (who uses these?):

  data
  keyword
it seems like you could have a web browser without the last 5 protocols... does
that make all of them candidates for removal from netwerk/?  i'm not sure...
afterall, keeping different protocol handlers in necko makes sense from the
point of view of "necko as a standalone library," but of course many of these
protocols are truly just extensions.

Comment 4

[benc]

+arch - we'll have to decide someday.

Comment 5

[Christopher Hoess (gone)]

*** Bug 106206 has been marked as a duplicate of this bug. ***

Comment 6

[Tom Everingham]

-> future

Comment 7

[Darin Fisher]

data should remain part of the core necko lib.  i'm not sure about keyword...

Comment 8

[Roland Mainz]

Please fix the protocols before moving them, some of them are still broken...
;-(

Comment 9

[Brian Ryner (not reading)]

Actually, it would make more sense to fix them after moving them, that way we
get non-working stuff out of the default build.

Comment 10

[Roland Mainz]

I've talked to darin few mins ago...
... I am going to overtake the "finger" module (see bug 165966 ('"finger"
protocol is broken') - I'll try to file a patch next week).

Comment 11

[Brian Ryner (not reading)]

Attachment: .tar.gz of extensions/datetime and extensions/finger

I didn't do this as a patch because I didn't want to cvs add the directories
until this gets reviewed.

Comment 12

[Brian Ryner (not reading)]

Attachment: patch

patch to existing files

Comment 13

[Roland Mainz]

Comment on attachment 97431 [details] [diff] [review]
patch

Please don't move finger, I am currently fixing it.

Comment 14

[Brian Ryner (not reading)]

Comment on attachment 97431 [details] [diff] [review]
patch

Why can't you fix it after it's moved? I'm not changing the source files at
all.

Comment 15

[Roland Mainz]

Brian Ryner wrote:
> Why can't you fix it after it's moved? I'm not changing the source files at
> all.

Because it doesn't make sense for me to fix it when noone can use it. Moving it
to extensions/ is a 100% gurantee that it will not be available in normal builds
nor in upcoming netscape releases.

Comment 16

[Doug Turner (:dougt)]

lets think about moving theme too.  beard?

Comment 17

[Brian Ryner (not reading)]

Then you're suggesting that this bug should be closed as INVALID/WONTFIX.  I
think that's up to darin.

Comment 18

[Darin Fisher]

Comment on attachment 97431 [details] [diff] [review]
patch

sr=darin (both patches)... i'm all for this patch.  we don't need to be loading
finger and datetime code whenever a user clicks on a FTP link.

Comment 19

[Roland Mainz]

Why aren't we simply removing the code completely (the current patch moves it
already in the trashcan/ dir (e.g. extensions not build by default)) ?

Comment 20

[cls]

Comment on attachment 97431 [details] [diff] [review]
patch

r=cls

Comment 21

[Roland Mainz]

Just some notes:
You're moving "finger" protocol support from the default build into the list of
extensions which are not build by default.
Side effects:
- No official netscape or mozila release will contain finger support anymore
- Even putting it on the list of extensions build by default won't work for
vendor releases which mainly using a hardcoded list of extensions they are
building. Getting finger support back into all these releases would mean to
contact _each_ _single_ vendor and beg to get it enabled again(=h*ll).

Comment 22

[Darin Fisher]

gisburn:

as you have repeatedly pointed out, the finger code is currently broken.  so, it
does not matter where we move it.  new mozilla/netscape builds will not be
anymore broken by this change.

some vendors do not want extra protocols like finger and datetime.  that is
another good reason to move these into the extensions folder.  it let's those
building applications on top of mozilla easily decide which components they want
to include.  it is not our job to force them into including code they don't
want.  some embedders are already modifying necko makefiles to exclude certain
protocol handlers.  bryner's patch only makes life easier for our embedders.

Comment 23

[Chris McAfee]

repo files copied to extensions/finger, extensions/datetime per bryner's email.

Comment 24

[Andreas Otte]

Arghhh ... I just updated nsFingerHandler.cpp and nsDateTimeHandler.cpp at their
old position under netwerk/protocol for the fix on bug 166085. 

Comment 25

[Andreas Otte]

Attachment: repeating fix for bug 166085 at new location

Comment 26

[Darin Fisher]

Comment on attachment 97560 [details] [diff] [review]
repeating fix for bug 166085 at new location

sr=darin (andreas: no need to wait for further code review on this... sorry for
not informing you about the finger/datetime move in the other bug!!)

Comment 27

[Brian Ryner (not reading)]

Checked this patch into the new location.

Comment 28

[Brian Ryner (not reading)]

Ok, checked in the file move to the trunk.

Comment 29

[benc]

Finger isn't even RFC specified, and there are options that the URL format
doesn't seem to support.

I think moving it would be the first priority, then doing some design specs
would be second, THEN fixing it, third.

Comment 30

[Patrick C. Beard]

No objection to moving theme protocol.

Comment 31

[benc]

So... did we follow the plan in #3? 

I was wondering how this will affect each of the mentioned protocols that is
changed (does it work in builds anymore, or do I have to do my own build w/
customized settings...)

Comment 32

[Darin Fisher]

benc: you have to do your own build to enable finger and datetime.  they are no
longer part of the default build.

Comment 33

[benc]

V: 
1.7 + Caminio 1.b1
protocols are not registered anymore