2 Feature suggestion/requests

Discussion re sg development. You don't have to be a developer.

2 Feature suggestion/requests

Postby rdigqd » Mon Aug 08, 2005 10:43 pm

Coupla noodlings I wanted to toss out for review, comment
and possible implementation....

1) "Group User/Owner" facility

I have a number of SG "user" accounts, created
according to various needs and preferences.

Somer of 'em are general 'buckets' for weeding out
krud and chaff from pearls and/or maintaining a
'disposable' email acct. Others are for special purpose
use (associated with a specific sender or as a filter for
a specific "real" e-mail id that has been burned but is
too widely known by valid senders to easily discard.)

It struck me that it'd be rather useful if I was able to
group all my SG user ids under a single 'master' login.
Then -- a la the "My Groups" login page for yahoo -- I
could easily log in once to then access each individual
id I have as desired.

2) Add'l "eaten msg" info: subject text

I spawned a discussion a while back on the
notion of increasing the number of 'eaten msgs'
logged above the current limit of three.

Apparently, there are technical reasons why that
number cannot be hiked. So be it.

More recently though, it struck me that having the
msg subject, as well as the putative sender's email
addr, shown in the "eaten" log could be helpful in
fine-tuning the whitelists setting for an SG user account.

Eg: I have an SG account used for sending out family
reunion announcements and news, and receiving
email back from the relatives involved. Burned big time
in the past by an account harvest on some family
members' machines that weren't protected and were
turned into zombie boxes -- hence I am now using the
SG account as a filter, with all valid _known_ family
members email addrs in the whitelist.
But, some members do from time to time change to
different ISPs (for $ benefits, due to a move, etc.)
and it'd be handy to have addl data in the eaten log
so I can sort out krud from valid family member msgs.

Other uses come to mind but that should suffice as
an example of what and why for this notion.

Comments?
Responses?
Questions?

Thanx again (and again and again...) for a wonderful,
darned near utterly vital product/service!!

j.
rdigqd
 
Posts: 24
Joined: Mon Feb 21, 2005 7:38 pm

Postby SysKoll » Wed Aug 10, 2005 2:01 am

It struck me that it'd be rather useful if I was able to group all my SG user ids under a single 'master' login. Then -- a la the "My Groups" login page for yahoo -- I could easily log in once to then access each individual id I have as desired.


I have exactly the same problem since I have several sg IDs. It turns out that a modern browser such as Mozilla or Firefox includes password management for you, and logging in to an SG account involves:
1. Entering the browser's master password
2. Picking an ID from the login name list

The password field is automatically filed in.

That's convenient enough for my purposes. I'd gladly redo the pages and the authentication, but I don't know the syntax of the template engine that Josh used for the web interface, so until I learn it, I won't criticize his pages. :-)

I spawned a discussion a while back on the notion of increasing the number of 'eaten msgs' logged above the current limit of three.

Apparently, there are technical reasons why that number cannot be hiked. So be it.

More recently though, it struck me that having the msg subject, as well as the putative sender's email addr, shown in the "eaten" log could be helpful in fine-tuning the whitelists setting for an SG user account.


It turns out it's the same problem. The limiting factor is the size of the DB. If we want to maintain a free server, we have to severely constrain the HD utilization. I'll discuss the idea with Josh. We'll pull some stats and see what this new field would imply. Meanwhile, I suggest that you post this idea as a poll in the appropriate section.
-- SysKoll
SysKoll
 
Posts: 893
Joined: Thu Aug 28, 2003 9:24 pm

Postby rdigqd » Thu Aug 11, 2005 1:02 am

Master Login
----------------
Pswd mgmt is not the challenge/quandary I face (or, I thought,
that I posited); rather, it is keeping track of the very roster
of SG ids I've created that is the issue.

too, ... I have noooo inclinatation at alllllll to use "pswd
management/storage" features -- whether in a browser
(modern or not) or in a separate programme offering.

Having a field available when an id is created (or modified)
that permits association with some other/"master" SG id,
and a companion feature that such id's are/can be shown
as sub-items in a list when one logs into that "master" id
keeps everything in the SG envelope (which I trust), and
doesn't require users to implemnent new s/w or ways of
operating their machines. (And, it is likely to be far more
accurate over time than the list I _try_ to maintain here
in a local .TXT file <G>)

Subject line info for "eaten" msgs
------------------------------------------
Reasonable comeback, though I'd add here that
only the existance of "some technical problem" was
id-at that previous time as the show-stopper -- not
_what_ that problem was, or, in particular, that it
was related to DB size. (Elsewise, I'd have groked
all on my own that adding storage space requirements
to an already heavily taxed storage facility was not
prudent! <G>)

Still.... it'd be helpful if even some _part_ of the subject
line (first 10-20 characters, let's say) could be
accomodated in some duff/slack/not-currently-used
portion of the DB records (assuming they're fixed
length, NOT variable length, records ... in order to
enhance look-up efficiency!!)

post this idea as a poll ....
--------------------------------
Thanx for the suggestion. Will investigate that section
of the BBS and see if I can up w/ something tp put up
there to to act on it.

j.
rdigqd
 
Posts: 24
Joined: Mon Feb 21, 2005 7:38 pm

Postby josh » Mon Aug 15, 2005 2:59 pm

As for the subject in the eaten message log, the story is that we tried using a database data type that would allow elements of arbitrary size, and it brought our server down -- for that reason, we used the largest fixed size type that was available (I think it's 255 or 256 characters), and came up with a system to squeeze in info regarding the last three messages. Working with 255, that means we had 65 characters per message to use - the particular disposable address and the time take, say, 20 of them, leaving 45 to store the sender address. We believed that we shouldn't cut the sender address to any less than that, but we could rethink that at some point. In any event, displaying a meaningful portion of the subject would eat up quite a bit of that 45 characters. We could probably make things work if we cut down to two messages instead of 3.


As for the grouping -- we can think about that. Since the logic would only come into play when you log in, it conceivably could not impact the handling of email very much, which is good.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

2 Feature suggestion/requests

Postby rdigqd » Tue Aug 16, 2005 9:02 pm

Hi, josh

-- fixed-lgth rcd db as suspected ... needed for hi-speed,
efficient processing!! Bummer the rcd lgth is as low as
you indicate ==>> log depth of 3 is already at the
bare minimum limit of usability for ensuring awareness
of "false"-deletions (viz: my rqst a bit ago for more
like 5-20 entries <G>)

Oh well....

-- looking fwd eagerly for an developments on the "owne"
id concept I put forth.

As you say, it'd matter nada at e-m processing (analysis
then consumption or forwarding), only when the
"owner"/"super"-user logs in, and in the matter of
keeping enuff info in the "child" id's to ident the link.

Thanx for the come-back and progress report.

j.
rdigqd
 
Posts: 24
Joined: Mon Feb 21, 2005 7:38 pm


Return to Developers

Who is online

Users browsing this forum: No registered users and 18 guests

cron