Gregg Young wrote:
> Hi
>
> The os2 toolkit indicates that the .subject ea has a 40 char limit.
> However, recent custom Mozilla build include a utility that will place a
> downloaded files url in the subject ea. This often exceeds the 40 char
> limit. The entire name is shown on the file page of the setting notebook
> (perhaps xworkplace or dragtext has modified this page) even if it
> exceeds the limit (up to at least 190 char). Why does this "limit" exist
> and is it still relevant? I would like to update fm/2 to read the longer
> strings or should I recommend that we change (fix) Mozilla to use a
> different ea for the url. I have changed the fm/2 subject ea to 256 for
> testing and have had no problems. Thanks
>
> Gregg

Awget and some versions of wget also write the URL in the subject EA as
well as name and date in comments. I haven't seen any problems here from
it. EAs seem to be preserved with copying and moving. Just the
properties box only displays 43 chars at a time here.
Dave

On Wed, 25 Jul 2007 14:53:04 UTC, Dave Yeo wrote:
> Gregg Young wrote:
> >
> > The os2 toolkit indicates that the .subject ea has a 40 char limit.
> > However, recent custom Mozilla build include a utility that will place a
> > downloaded files url in the subject ea. This often exceeds the 40 char
> > limit. The entire name is shown on the file page of the setting notebook
> > (perhaps xworkplace or dragtext has modified this page) even if it
> > exceeds the limit (up to at least 190 char). Why does this "limit" exist
> > and is it still relevant? I would like to update fm/2 to read the longer
> > strings or should I recommend that we change (fix) Mozilla to use a
> > different ea for the url. I have changed the fm/2 subject ea to 256 for
> > testing and have had no problems. Thanks
>
> Awget and some versions of wget also write the URL in the subject EA as
> well as name and date in comments. I haven't seen any problems here from
> it. EAs seem to be preserved with copying and moving. Just the
> properties box only displays 43 chars at a time here.

AFAICT, the 40-character limit is arbitrary. Perhaps IBM had some plans
for this EA which were never implemented. Mike Kaply el al. chose to
use .SUBJECT when they implemented this feature in Netscape, so I felt
compelled to do likewise when I recreated it in Mozilla (personally, I
would have chosen some other EA).

For FM/2, I wouldn't establish any limit on the length of the EA. The
mozapps write out whatever they're given - and that could easily be
500+ characters.


--
== == almost usable email address: rws AT e-vertise.com == ==
__________________________________________________ _________________
|
| Remote Workplace Server v0.80
Rich Walsh | interact with the WPS from any program
Ft Myers, FL | http://e-vertise.com/rws/rws080.zip
__________________________________________________ _________________

Rich Walsh wrote:
> On Wed, 25 Jul 2007 14:53:04 UTC, Dave Yeo wrote:
>> Gregg Young wrote:
>>> The os2 toolkit indicates that the .subject ea has a 40 char limit.
>>> However, recent custom Mozilla build include a utility that will place a
>>> downloaded files url in the subject ea. This often exceeds the 40 char
>>> limit. The entire name is shown on the file page of the setting notebook
>>> (perhaps xworkplace or dragtext has modified this page) even if it
>>> exceeds the limit (up to at least 190 char). Why does this "limit" exist
>>> and is it still relevant? I would like to update fm/2 to read the longer
>>> strings or should I recommend that we change (fix) Mozilla to use a
>>> different ea for the url. I have changed the fm/2 subject ea to 256 for
>>> testing and have had no problems. Thanks
>> Awget and some versions of wget also write the URL in the subject EA as
>> well as name and date in comments. I haven't seen any problems here from
>> it. EAs seem to be preserved with copying and moving. Just the
>> properties box only displays 43 chars at a time here.
>
> AFAICT, the 40-character limit is arbitrary. Perhaps IBM had some plans
> for this EA which were never implemented. Mike Kaply el al. chose to
> use .SUBJECT when they implemented this feature in Netscape, so I felt
> compelled to do likewise when I recreated it in Mozilla (personally, I
> would have chosen some other EA).
>
> For FM/2, I wouldn't establish any limit on the length of the EA. The
> mozapps write out whatever they're given - and that could easily be
> 500+ characters.
>
>
IRRC Mike chose the subject EA because that was what awget was already
using, though I could be misremembering.
Dave

On Wed, 25 Jul 2007 04:36:04 UTC, Gregg Young wrote:

> The os2 toolkit indicates that the .subject ea has a 40 char limit.
> However, recent custom Mozilla build include a utility that will place a
> downloaded files url in the subject ea. This often exceeds the 40 char
> limit. The entire name is shown on the file page of the setting notebook
> (perhaps xworkplace or dragtext has modified this page) even if it
> exceeds the limit (up to at least 190 char). Why does this "limit" exist
> and is it still relevant? I would like to update fm/2 to read the longer
> strings or should I recommend that we change (fix) Mozilla to use a
> different ea for the url. I have changed the fm/2 subject ea to 256 for
> testing and have had no problems. Thanks

Interesting, Jim Read contacted me with the same question for
FileStar/2. Unfortunately my reply could not be delivered as his address
was not recognized by his provider. Perhaps he reads this here.

He suggested to switch from SUBJECT EA to COMMENT for URLs of downloaded
files, but if -- as I read in this thread -- AWGet already uses SUBJECT
then this doesn't make sense.

Also, I can nicely type 260 chars in the SUBJECT EA field of the
properties dialog with xWorkplace installed. So any app dealing with the
SUBJECT EA should better accommodate long SUBJECT EAs (even if Mozilla
and AWGet would be changed).
--
Greetings, | My From: address is valid as is the version without "spam"
Peter. | I try to find real messages among the spam once a week

On Thu, 26 Jul 2007 03:54:46 UTC, Dave Yeo wrote:

> IRRC Mike chose the subject EA because that was what awget was already
> using, though I could be misremembering.

That should be "Rich chose" because it was his patch... But otherwise
you are right. AWGet indeed uses the SUBJECT EA for the URL and the
COMMENT EA for the title (of the WPS URL object) and the date. It's not
documented in its ReadMe but in the "changes" file.
--
Greetings, | My From: address is valid as is the version without "spam"
Peter. | I try to find real messages among the spam once a week

On Mon, 30 Jul 2007 15:15:07 UTC, "Peter Weilbacher" wrote:
> On Wed, 25 Jul 2007 04:36:04 UTC, Gregg Young wrote:
>
> > The os2 toolkit indicates that the .subject ea has a 40 char limit.
> > However, recent custom Mozilla build include a utility that will place a
> > downloaded files url in the subject ea. This often exceeds the 40 char
> > limit.
>
> Interesting, Jim Read contacted me with the same question for
> FileStar/2. Unfortunately my reply could not be delivered as his address
> was not recognized by his provider. Perhaps he reads this here.

Peter cc'd me on this & my reply to Jim also bounced.

It seemed that Jim's primary concern was that a long .SUBJECT EA results
in an excessively wide column when in details view. This is seen as an
issue in FS/2 and possibly FM/2 as well. IMHO, this is something that
any developer can rectify with a little bit of effort. One needn't be
a "victim" of long strings or the container control's default behavior.

The quick-and-dirty solution is, of course, to simply truncate the data.
The preferrable way (IMHO) is to override the container's default
autosizing feature and set a fixed width for the column. If you want
to go the extra mile, you can make the column user-sizable. That's
what I've done in apps like Iconomize, FPos & Cameraderie. All of
these are open-source so anyone can use them as an example of how to:
determine a column's current (autosized) width; set a fixed width;
and restore autosizing. The applicable code for each app is in
???COL.C


--
== == almost usable email address: rws AT e-vertise.com == ==
__________________________________________________ _________________
|
| Remote Workplace Server v0.80
Rich Walsh | interact with the WPS from any program
Ft Myers, FL | http://e-vertise.com/rws/rws080.zip
__________________________________________________ _________________

In , on 07/30/2007
at 05:38 PM, "Rich Walsh" said:

Hi,

>It seemed that Jim's primary concern was that a long .SUBJECT EA results
>in an excessively wide column when in details view. This is seen as an
>issue in FS/2 and possibly FM/2 as well.

It's only an issue for fm/2 because the column width and ordering is not
user user control at this time. However, it's a couple of mouse clicks to
hide and unhide the column and no one has yet complained about excessive
width.

>IMHO, this is something that
>any developer can rectify with a little bit of effort.

Agreed. That would be the solution I would recommend.

IMO, the only reason to limit the size of an EA is if a longer EA breaks
the WPS.

Regards,

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine MR2/ICE 3.00 beta 08pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

>
> It's only an issue for fm/2 because the column width and ordering is not
> user user control at this time. However, it's a couple of mouse clicks to
> hide and unhide the column and no one has yet complained about excessive
> width.

I agree that the column width is a non issue. It can be hidden or can be
scrolled off the screen easily (where it stays).

>
>> IMHO, this is something that
>> any developer can rectify with a little bit of effort.
>
> Agreed. That would be the solution I would recommend.
>
> IMO, the only reason to limit the size of an EA is if a longer EA breaks
> the WPS.

I asked the question to determine if the limit was there for a reason. I
didn't want to break something unnecessarily. I am comfortable it is an
arbitrary limit and if IBM was going to enforce it in some way; they
never followed through. Thanks to everyone for their responses.

Gregg

On Jul 30, 1:38 pm, "Rich Walsh" wrote:
> On Mon, 30 Jul 2007 15:15:07 UTC, "Peter Weilbacher" wrote:
> > On Wed, 25 Jul 2007 04:36:04 UTC, Gregg Young wrote:
>
> > > The os2 toolkit indicates that the .subject ea has a 40 char limit.
> > > However, recent custom Mozilla build include a utility that will place a
> > > downloaded files url in the subject ea. This often exceeds the 40 char
> > > limit.
>
> > Interesting, Jim Read contacted me with the same question for
> > FileStar/2. Unfortunately my reply could not be delivered as his address
> > was not recognized by his provider. Perhaps he reads this here.
>
> Peter cc'd me on this & my reply to Jim also bounced.
>
> It seemed that Jim's primary concern was that a long .SUBJECT EA results
> in an excessively wide column when in details view. This is seen as an
> issue in FS/2 and possibly FM/2 as well. IMHO, this is something that
> any developer can rectify with a little bit of effort. One needn't be
> a "victim" of long strings or the container control's default behavior.
>
> The quick-and-dirty solution is, of course, to simply truncate the data.
> The preferrable way (IMHO) is to override the container's default
> autosizing feature and set a fixed width for the column. If you want
> to go the extra mile, you can make the column user-sizable. That's
> what I've done in apps like Iconomize, FPos & Cameraderie. All of
> these are open-source so anyone can use them as an example of how to:
> determine a column's current (autosized) width; set a fixed width;
> and restore autosizing. The applicable code for each app is in
> ???COL.C

Thanks to all who have responded. FS/2 has user ordered columns and a
subject column fixed width of 40, truncating any longer subject EA. So
it handles these ok as it is. There are other places like creating the
subject EA that needs a entry length fix. I was concerned about
violating the docs as much as anything although I thought when I wrote
to Peter that the column would be excessively wide in details - before
I looked.

The .HISTORY EA makes more sense to me except for breaking the other
apps that already use the subject EA. I also think having URL info in
details view is not very useful. Probably only affects FS/2 and FM/2.
I'll deal with it.

I don't understand the inability to send me email. Will follow up on
this. I certainly get lots of email at the address I used.

Jim Read

Peter Weilbacher wrote:
> On Thu, 26 Jul 2007 03:54:46 UTC, Dave Yeo wrote:
>
>> IRRC Mike chose the subject EA because that was what awget was already
>> using, though I could be misremembering.
>
> That should be "Rich chose" because it was his patch... But otherwise
> you are right. AWGet indeed uses the SUBJECT EA for the URL and the
> COMMENT EA for the title (of the WPS URL object) and the date. It's not
> documented in its ReadMe but in the "changes" file.

Actually we're all misremembering Rich in the grandparent post said
he used the SUBJECT and COMMENT EAs because Mike used them in NS4.61. I
guessed that Mike used them in NS4.61 due to AWget using them.
I just tested by downloading a file with NS4.61 and the only EA written
was .CLASSINFO. So Rich was the first one to implement it in an OS/2
browser but probably followed AWgets lead, not NS4.61.
Of course I could still be misremembering, not getting any younger
Dave

On Thu, 2 Aug 2007 02:21:09 UTC, Dave Yeo wrote:
>
> Actually we're all misremembering Rich in the grandparent post said
> he used the SUBJECT and COMMENT EAs because Mike used them in NS4.61. I
> guessed that Mike used them in NS4.61 due to AWget using them.
> I just tested by downloading a file with NS4.61 and the only EA written
> was .CLASSINFO. So Rich was the first one to implement it in an OS/2
> browser but probably followed AWgets lead, not NS4.61.
> Of course I could still be misremembering, not getting any younger

From a comment I appended to Bugzilla #301367:

> FYI... this is simply a reimplementation of a feature Mike Kaply added
> to the OS/2 port of Netscape 2.02.


--
== == almost usable email address: rws AT e-vertise.com == ==
__________________________________________________ _________________
|
| Remote Workplace Server v0.80
Rich Walsh | interact with the WPS from any program
Ft Myers, FL | http://e-vertise.com/rws/rws080.zip
__________________________________________________ _________________

Sir:

Dave Yeo wrote:
> Peter Weilbacher wrote:
>> On Thu, 26 Jul 2007 03:54:46 UTC, Dave Yeo wrote:
>>
>>> IRRC Mike chose the subject EA because that was what awget was
>>> already using, though I could be misremembering.
>>
>> That should be "Rich chose" because it was his patch... But otherwise
>> you are right. AWGet indeed uses the SUBJECT EA for the URL and the
>> COMMENT EA for the title (of the WPS URL object) and the date. It's
>> not documented in its ReadMe but in the "changes" file.
>
> Actually we're all misremembering Rich in the grandparent post said
> he used the SUBJECT and COMMENT EAs because Mike used them in NS4.61. I
> guessed that Mike used them in NS4.61 due to AWget using them.
> I just tested by downloading a file with NS4.61 and the only EA written
> was .CLASSINFO. So Rich was the first one to implement it in an OS/2
> browser but probably followed AWgets lead, not NS4.61.
> Of course I could still be misremembering, not getting any younger

How we mis-remember. Does anyone remember Dlurlea.cmd that Veit wrote?
here is part of the readme:
user documentation DLURLEA Veit Kannegieser
************************************************** ************************

usage: DLURLEA.CMD

It will search the %HOME%\Mozilla subdirs for downloads.rdf and
attach an .URL/.SUBJECT EA to all files that still exist in
the download directory containing the URL it was donwloaded from.
-----
I believe that it was a thread that I comment within praising this in
which Rich said that he could do that as part of his tool. I still use
this with the official build whenever I test out that product.
--
Bill
Thanks a Million!