quoting in public from archive, is it tolerable?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

quoting in public from archive, is it tolerable?

Peter Princz
Hello world,

I never had a homepage before, but now gave a try to googlepages,
because soon I'll have to put together a site for my wife.
Anyway, just wanted to make use of the opportunity (as alwayas :) and
gathered all the relevant details I'd mention to an unknown human
being.
Of course, vimoutliner is on the top of the list. :)

I took my liberty to quote some interesting thoughts that appeared on
our list also, incl. some sentences written by others. So far I
haven't done any "advertisement" to these pages, and I can unpublish
if you consider it as a violation.

See them here:
http://princzp.googlepages.com/
http://princzp.googlepages.com/vimoutliner

So: do these hurt anyone here? Please feel free to send any objections
on list or in private. Thank you!

Have a nice day,
  Peter

--
Keep cool. Develop in total darkness.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: quoting in public from archive, is it tolerable?

Steve Litt
Hi Peter,

I have no objections so I won't write you in private.

First, I am not a lawyer (IANAL)...

My personal opinion has always been that once you email a mailing list, your
email belongs to the public. A person posting to emailing to a list has
absolutely no "expectation of privacy". "Expectation of privacy" is a
buzzphrase of American law. If your activity has no "expectation of privacy",
then you are not protected by the fourth amendment of the US constitution. In
other words, I think if a person posts to a mailing list, that person gives
implicit permission for others to further copy that info, always assuming
such a copy is performed in context, and that the email wouldn't be
considered a copyrightable work (source code, poem, something more than
correspondence).

There are a few complications:

1) The "Creative Commons" license. This is an attempt to tell others how to
use the email. I personally wish people wouldn't put that license on emails.
Personally, I would not quote from an email with the Creative Commons
license. Life's too short for such complications.

2) Copyrights. Perhaps some of the email is copyrighted. For instance, if I
send out an update to vo_maketags.pl complete with a GPL license, one could
not use the copyrighted part of the email in ways other than the
copyright/license permits. Quoting from other parts is fine. Personally, I
think that if anyone ever copyrighted his *whole* email, that person has too
big an ego and too much time on his hands.

3) Flamewars, accusations etc. I would not quote an email containing a phrase
like "Vergosynovich is an ignorant hypocrite whose intent is to ruin
VimOutliner". Although the author gave away his expectation of privacy, you
could be spreading slanted material at best, untruths at worst. I would not
quote from any part of such an email, because complete context would require
the reader to read the nastiness.

4) Those silly sigs that megacorps and law offices put on the bottom of the
email saying that this is private information and you must not disclose it.
Once again, life is too short to risk running afoul of that stuff -- I doubt
it would stand up in court, but nobody wants to have to go to court to find
out. Personally, I think that anyone whose employer insists on tacking on
that piece of tackiness should subscribe with a personal email address, or
none at all.

5) Patents, trade secrets, etc. These should have never made it to a public
mailing list in the first place, and the last thing you want to do is embroil
yourself in the poster's legal problems by copying it further.

Anyway, those are my opinions for forming the basis of what should be copyable
and what shouldn't.

HTH

SteveT

On Monday 23 October 2006 05:23 am, Peter Princz wrote:

> Hello world,
>
> I never had a homepage before, but now gave a try to googlepages,
> because soon I'll have to put together a site for my wife.
> Anyway, just wanted to make use of the opportunity (as alwayas :) and
> gathered all the relevant details I'd mention to an unknown human
> being.
> Of course, vimoutliner is on the top of the list. :)
>
> I took my liberty to quote some interesting thoughts that appeared on
> our list also, incl. some sentences written by others. So far I
> haven't done any "advertisement" to these pages, and I can unpublish
> if you consider it as a violation.
>
> See them here:
> http://princzp.googlepages.com/
> http://princzp.googlepages.com/vimoutliner
>
> So: do these hurt anyone here? Please feel free to send any objections
> on list or in private. Thank you!
>
> Have a nice day,
>   Peter

--
Steve Litt
Author:
   * Universal Troubleshooting Process courseware
   * Troubleshooting Techniques of the Successful Technologist
   * Manager's Guide to Technical Troubleshooting
   * Twenty Eight Tales of Troubleshooting
   * Rapid Learning: Secret Weapon of the Successful Technologist

http://www.troubleshooters.com/bookstore
http://www.troubleshooters.com/utp/tcourses.htm

(Legal Disclaimer) Follow these suggestions at your own risk.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: quoting in public from archive, is it tolerable?

Tim Roberts
In reply to this post by Peter Princz
Peter Princz wrote:

>
> I never had a homepage before, but now gave a try to googlepages,
> because soon I'll have to put together a site for my wife.
> Anyway, just wanted to make use of the opportunity (as alwayas :) and
> gathered all the relevant details I'd mention to an unknown human
> being.
> ...
> See them here:
> http://princzp.googlepages.com/


Did you author this using vim, or with some kind of HTML writer?

It's a curious phenomenon of this style-sheet age that your main page
contains 18k bytes of CSS in order to render less than 3k bytes of text...

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
In reply to this post by Peter Princz
* Peter Princz <[hidden email]> wrote:
> See them here:
> http://princzp.googlepages.com/vimoutliner

So, under the "limits" section, you mention wanting to represent
graphs instead of strict trees.

That's something I've given a lot of thought to over the past 5-6
years, and I'm about to start work on a fifth prototype
filesystem designed for this kind of thing.

Basically, I've been looking for a filesystem which represents a
directed graph instead of a tree.  So, it's still hierarchic, but
instead of each node having one parent and multiple children, it
would be multiple parents and multiple children.  It's like
hierarchic labels or tags, built into the filesystem.

If reiserfs4 allowed this, I'd have a good basis for building
apps.  But POSIX forbids multiple hardlinks to directories, and
has no decent way to "ls" parents, so I'm stuck using more custom
storage to represent the graph.

While it's a really neat idea and I'm interested in building it,
I don't see this sort of thing being feasible in VO.  Since it's
primarily a text editor, using plaintext storage, it seems
like graphs would be very difficult and kludgy to implement.

OTOH, VO almost makes me want to write v2 of my old outliner
program.  VO has incredible text-editing capabilities, but it's
fairly weak on the actual tree manipulation.  It would be nice to
have something more like a hierarchic database, where each node
can have its own unique set of attributes.  But I don't know how
much I would actually use something like that, so I doubt I'll
write it.  VO is arguably more useful most of the time, even if
it is just a folding text editor with some macros and export
plugins.


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: quoting in public from archive, is it tolerable?

Peter Princz
In reply to this post by Tim Roberts
Hi Tim,

On 23/10/06, Tim Roberts <[hidden email]> wrote:

> Peter Princz wrote:
>
> >
> > I never had a homepage before, but now gave a try to googlepages,
> > because soon I'll have to put together a site for my wife.
> > Anyway, just wanted to make use of the opportunity (as alwayas :) and
> > gathered all the relevant details I'd mention to an unknown human
> > being.
> > ...
> > See them here:
> > http://princzp.googlepages.com/
>
>
> Did you author this using vim, or with some kind of HTML writer?
>
> It's a curious phenomenon of this style-sheet age that your main page
> contains 18k bytes of CSS in order to render less than 3k bytes of text...
>
> --
> Tim Roberts, [hidden email]
> Providenza & Boekelheide, Inc.

as I wrote, it's "authored" with googlepages, i.e. yes, the original
text is written with vim (it'is my outline file), than the pages were
copy-pasted into googlepages and formatted with bullets, and finally
the links were added. That's it, 5+ pages in less then 5 minutes.

The 18k/3k css/content ratio is yes, strange in my case, but please
appreciate it's really light content there. I don't want to defend
googlepages, but I think even with average content of modern webpages
(more text, pictures!, or even bg sound) the css overhead gets
unnoticed...

Have a nice day,
  Peter

--
Keep cool. Develop in total darkness.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Peter Princz
In reply to this post by Scott Scriven-2
Scott,

On 23/10/06, Scott Scriven <[hidden email]> wrote:

> * Peter Princz <[hidden email]> wrote:
> > See them here:
> > http://princzp.googlepages.com/vimoutliner
>
> So, under the "limits" section, you mention wanting to represent
> graphs instead of strict trees.
>
> That's something I've given a lot of thought to over the past 5-6
> years, and I'm about to start work on a fifth prototype
> filesystem designed for this kind of thing.
>
> Basically, I've been looking for a filesystem which represents a
> directed graph instead of a tree.  So, it's still hierarchic, but
> instead of each node having one parent and multiple children, it
> would be multiple parents and multiple children.  It's like
> hierarchic labels or tags, built into the filesystem.
>
> If reiserfs4 allowed this, I'd have a good basis for building
> apps.  But POSIX forbids multiple hardlinks to directories, and
> has no decent way to "ls" parents, so I'm stuck using more custom
> storage to represent the graph.
>
> While it's a really neat idea and I'm interested in building it,
> I don't see this sort of thing being feasible in VO.  Since it's
> primarily a text editor, using plaintext storage, it seems
> like graphs would be very difficult and kludgy to implement.
>
> OTOH, VO almost makes me want to write v2 of my old outliner
> program.  VO has incredible text-editing capabilities, but it's
> fairly weak on the actual tree manipulation.  It would be nice to
> have something more like a hierarchic database, where each node
> can have its own unique set of attributes.  But I don't know how
> much I would actually use something like that, so I doubt I'll
> write it.  VO is arguably more useful most of the time, even if
> it is just a folding text editor with some macros and export
> plugins.
>
>

supporting an important feature down to filesystem level is a
brilliiant idea, I enceourage you to elaborate on that. Version
control was once built into VMS, regarded as the best ever OS by many
old folks. Also one of the success factors behind Unix is how they map
almost every concept to files and provides efficient tools to
manipulate files. Soft- and hard links on unix (shortcuts on windows)
is a nice try to abstract from trees to graphs there. So don't give
up. :)

Particularly reiserfs has clouded future now, that its author has been
arrested and also Novell has dropped it.

Have a nice day,
  Peter

--
Keep cool. Develop in total darkness.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
* Peter Princz <[hidden email]> wrote:
> supporting an important feature down to filesystem level is a
> brilliiant idea, I enceourage you to elaborate on that.

There are just filesystem concepts I keep finding a need for, and
no solution seems to exist yet.  Originally I just wanted a photo
album with hierarchic categories where each image could be a
member of more than one category without making multiple copies.
A lot of the time, such categories can replace tags, labels,
keywords, or attributes.

For example, if I have a photo containing three people at a
halloween party, I might put it in a few categories:

  /people/bob
  /people/sue
  /people/zed
  /events/halloween/2006
  /places/zeds_house
  /dates/2006/10/31
  /photographers/scott  (I took the picture)

Other users might also add it to more categories.  If Mary likes
it, she might add it to /users/mary/favorites.  Or she might do a
search for "zed AND bob" and then browse the results at
/tmp/searches/20061102123043/.  If she really cared about the
search results, she could copy the entire thing to a more
permanent spot.  That's 9 categories for a single file so far,
and it barely scratches the surface.

As a somewhat insane/extreme example, imagine if the owner of a
file was a category instead of an attribute.  In the photo
example, the entries for /users/scott and
/people/bob/foo.jpg/..owner may actually be the same file.
I could then easily list all files I own with a simple "cd
/users/scott ; ls .." or similar.

> one of the success factors behind Unix is how they map almost
> every concept to files and provides efficient tools to
> manipulate files.

That was my favorite part of reiser4.  It treats files, dirs, and
attributes as the same basic type, and provides plugins to extend
that even to individual records within files.  So, you can "vim
mysong.mp3/.title" or "cp foo/..uid bar/..uid" instead of using a
special mp3 tag program or chown.

> Soft- and hard links on unix (shortcuts on windows) is a nice
> try to abstract from trees to graphs there.  So don't give up.
> :)

Symlinks are nice, but annoyingly one-directional.  The
abstraction is a bit thin.  I used symlinks to simulate a graph
in my previous prototype, and it just got out of hand.  I need
real bidirectional links to make things work correctly.  Symlinks
worked okay for the ~20,000 nodes in my test system, but they
would be completely inadequate for the many-million-node systems
I'm hoping to build.

> Particularly reiserfs has clouded future now, that its author
> has been arrested and also Novell has dropped it.

Yeah.  I'm sad.

I mean, I've read some of Reiser's kernel list posts.  I wouldn't
be terribly surprised if he's guilty.  But I selfishly hope he
didn't do it, since he was leading a field of research I care
about.


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Tim Roberts
Scott Scriven wrote:
* Peter Princz [hidden email] wrote:
  
supporting an important feature down to filesystem level is a
brilliiant idea, I enceourage you to elaborate on that.
    

There are just filesystem concepts I keep finding a need for, and
no solution seems to exist yet.  Originally I just wanted a photo
album with hierarchic categories where each image could be a
member of more than one category without making multiple copies.
A lot of the time, such categories can replace tags, labels,
keywords, or attributes.
  

You may find that you actually like Windows Vista.  They're pushing this category/attribute concept in a big way.
-- 
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Steve Litt
In reply to this post by Scott Scriven-2
On Monday 23 October 2006 03:05 pm, Scott Scriven wrote:

> * Peter Princz <[hidden email]> wrote:
> > See them here:
> > http://princzp.googlepages.com/vimoutliner
>
> So, under the "limits" section, you mention wanting to represent
> graphs instead of strict trees.
>
> That's something I've given a lot of thought to over the past 5-6
> years, and I'm about to start work on a fifth prototype
> filesystem designed for this kind of thing.
>
> Basically, I've been looking for a filesystem which represents a
> directed graph instead of a tree.  So, it's still hierarchic, but
> instead of each node having one parent and multiple children, it
> would be multiple parents and multiple children.  It's like
> hierarchic labels or tags, built into the filesystem.
>
> If reiserfs4 allowed this, I'd have a good basis for building
> apps.  But POSIX forbids multiple hardlinks to directories, and
> has no decent way to "ls" parents, so I'm stuck using more custom
> storage to represent the graph.
>
> While it's a really neat idea and I'm interested in building it,
> I don't see this sort of thing being feasible in VO.  Since it's
> primarily a text editor, using plaintext storage, it seems
> like graphs would be very difficult and kludgy to implement.
>
> OTOH, VO almost makes me want to write v2 of my old outliner
> program.  VO has incredible text-editing capabilities, but it's
> fairly weak on the actual tree manipulation.  It would be nice to
> have something more like a hierarchic database, where each node
> can have its own unique set of attributes.  But I don't know how
> much I would actually use something like that, so I doubt I'll
> write it.  VO is arguably more useful most of the time, even if
> it is just a folding text editor with some macros and export
> plugins.

Hi Scott,

A guy named Gabriel Horner, who used to be on this list (maybe still is, but
hasn't posted for awhile), came to my house one day and demonstrated a DBMS
hosted version of VO. It wasn't very complete, but all the things that VO
just can't do well because of its basic single parent hierarchy assumption,
could be done quite easily in a database.

One could make an argument that a DBMS (mysql?) based VO backend would be
every bit as efficient as the current one, if:

1) All keystrokes were the same (I personally think the keystrokes are what
make VO so darned quick)

2) Outlines can be easily and quickly exported to tab indented format (in
other words, the current native format)

3) All features are included (body text, interoutline linking, executable
lines, checkboxes, hoisting)

Imagine how nice it would be to have each headline have a boolean datafield
called "in-use". Think that might make hoisting a little easier? With a DBMS
backend, clone headlines become a nobrainer.

Of course, someone would need to write a front end that implements VO
keystrokes and look and feel...

SteveT
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Peter Princz
Steve,

On 26/10/06, Steve Litt <[hidden email]> wrote:
>
> Of course, someone would need to write a front end that implements VO
> keystrokes and look and feel...
>

how about keeping vim for that? If we can use
vim/emacs/msword/lotuswordpro/etc. to compile an email, i.e. the pop3
client can fire up an external app for editing session and then
continue, then sure vim could be fired up with the text field of the
data row you've chosen in the DB...

Have a nice day,
  Peter

--
Keep cool. Develop in total darkness.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
In reply to this post by Tim Roberts
* Tim Roberts <[hidden email]> wrote:
> You may find that you actually like Windows Vista.  They're
> pushing this category/attribute concept in a big way.

*shrug*

I thought WinFS got cancelled more than a year ago.  ... Even if
not, though, I'm skeptical.  I haven't liked any release of
Windows yet, so it's hard to get excited about it.  :)


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
In reply to this post by Steve Litt
* Steve Litt <[hidden email]> wrote:
> One could make an argument that a DBMS (mysql?) based VO
> backend would be every bit as efficient as the current one, if:
>
> 1) All keystrokes were the same (I personally think the
> keystrokes are what make VO so darned quick)

That's a very difficult part.  There just aren't any other
editors quite like vim.  Vim could be called as an external
editor, but that loses most of the tight integration VO has.

> 3) All features are included (body text, interoutline linking,
> executable lines, checkboxes, hoisting)

What I had in mind to build, at least for an outliner, was
filesystem-based instead of SQL.  Each outline would essentially
be a directory tree with specially-named files.  Any directory
could be loaded as a tree, so each node would also be usable (or
hoistable) as a standalone tree.  Each node could have its own
unique set of attributes, including body text, executable
commands, checkboxes, dates, calculated fields, etc.  Linking
between nodes (or outlines, makes no difference) could be done
with symlinks, though there are a lot of "fiddly bits" to
complicate things when symlinks are used.  Real bidirectional
links would be necessary for any large trees.

For a larger system, the only solution I've been able to find is
to store the tree structure in a database and put file data
(pictures, music, etc) in a specially-constructed part of the
host filesystem.  Hopefully I'll be able to map the semantics
well enough to make it FUSE-mountable.

> Of course, someone would need to write a front end that
> implements VO keystrokes and look and feel...

Yes, not at all an easy task.  VO's feature set may be fairly
basic, but it builds on top of vim, and reimplementing vim would
be silly.


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Detlef Steuer
> For a larger system, the only solution I've been able to find is
> to store the tree structure in a database and put file data
> (pictures, music, etc) in a specially-constructed part of the
> host filesystem.  Hopefully I'll be able to map the semantics
> well enough to make it FUSE-mountable.

It seems a very reasonable way to use not a file but a filesystem as outliner.
Do you have anything nearly usable coded for fuse?

detlef

>
> > Of course, someone would need to write a front end that
> > implements VO keystrokes and look and feel...
>
> Yes, not at all an easy task.  VO's feature set may be fairly
> basic, but it builds on top of vim, and reimplementing vim would
> be silly.
>
>
> -- Scott
> _______________________________________________
> VimOutliner mailing list
> [hidden email]
> http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
* Detlef Steuer <[hidden email]> wrote:
> > Hopefully I'll be able to map the semantics well enough to
> > make it FUSE-mountable.
>
> It seems a very reasonable way to use not a file but a
> filesystem as outliner.  Do you have anything nearly usable
> coded for fuse?

No, but I'm planning to piggyback on NaNoWriMo this year and try
to get something usable by the end of November.  I'm not sure if
the FUSE parts will get done during that time, though.  My
priority for now is to get back end stuff, a basic CLI tool, and
a web interface working well enough to import the 100,000 records
from my previous prototype.


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Steve Litt
On Friday 27 October 2006 11:55 am, Scott Scriven wrote:

> * Detlef Steuer <[hidden email]> wrote:
> > > Hopefully I'll be able to map the semantics well enough to
> > > make it FUSE-mountable.
> >
> > It seems a very reasonable way to use not a file but a
> > filesystem as outliner.  Do you have anything nearly usable
> > coded for fuse?
>
> No, but I'm planning to piggyback on NaNoWriMo this year and try
> to get something usable by the end of November.  I'm not sure if
> the FUSE parts will get done during that time, though.  My
> priority for now is to get back end stuff, a basic CLI tool, and
> a web interface working well enough to import the 100,000 records
> from my previous prototype.

Will this work both for Linux and Windows, considering their different
filesystems?

SteveT
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner
Reply | Threaded
Open this post in threaded view
|

Re: graphs/trees

Scott Scriven-2
* Steve Litt <[hidden email]> wrote:
> Will this work both for Linux and Windows, considering their
> different filesystems?

Not likely.  It might be possible to get some back end parts
working on windows -- postgres, filesystem stuff, and python.
But a lot of the application and interface code I want to put on
top probably won't work on windows.  FUSE definitely won't work,
the batch job runner won't work, and I doubt the web interface
will be very portable.

I suppose windows support might be interesting.  I think it will
probably be limited to supporting windows web browsers, though.

OTOH, a filesystem-based outliner could probably work on windows.
It's the bigger project, a new file store for building apps on,
which wouldn't be very portable.


-- Scott
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner