Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^3: The ability to delete (self reap)

by tye (Sage)
on Oct 26, 2005 at 01:08 UTC ( #502916=note: print w/replies, xml ) Need Help??

in reply to Re^2: The ability to delete
in thread The ability to delete

That'd be less ugly than an empty node or even one full of long stretches of striked text...

It wouldn't make the node owned by the NodeReaper, which leads to questions like unreaping and exclusion from searches, etc.

On the other hand, it is uglier than a node with a mature update that is more informative and customized to the specific circumstances.

On the gripping hand, I don't foresee such getting implemented anyway. So I'm not going try to hash out more details of the design. (I prefer the previously identified route of getting preview for updates and then edit histories).

- tye        

  • Comment on Re^3: The ability to delete (self reap)

Replies are listed 'Best First'.
Re^4: The ability to delete (self reap)
by McDarren (Abbot) on Oct 26, 2005 at 02:48 UTC
    (I prefer the previously identified route of getting preview for updates and then edit histories).

    I'm curious about this....
    I certainly appreciate having the preview button available when creating a node, and I miss it when when updating.

    I tried a Super Search on "previewing updates" which turned up nothing. Is there a separate discussion on this elsewhere, or plans to implement it?

      Sorry, I don't have a ready pointer to a node on this subject nor a good lead on a quick way to find one.

      One reason for preview is to reduce the number of changes that get logged. I suspect that additional tricks will be required to reduce the resource requirements for logging changes to a reasonable level, though. We already have previews (and change logging) for other types of updates.

      - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://502916]
[davido]: I am not finding closing STDIN to be an adequate means of making getlogin return undef.
[Corion]: Maybe doing a double-fork (daemonizing) can make go that information away, but maybe not
[Corion]: But I think my knowledge of unix/Linux datastructures is several decades out of date, so I don't really know what information it keeps on processes
[oiskuu]: The useful bits that relate to your process can be found under /proc/self. What information are you thinking of? Tty name?
[tye]: I just daemonized and getlogin() still knew who I had been.
[tye]: perhaps loginuid ? Not that I concede that something not being in /proc means it is not useful.

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2017-06-23 19:32 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (554 votes). Check out past polls.