zim-wiki team mailing list archive

[Brian Allen Vanderburg II <brianvanderburg2@xxxxxxx>]

I like the idea of the archive being separately searchable instead of
showing up in completion and search.  As far as the conflict issue, I
think if we consider that once Foo is moved to the archive, a newly
created item Foo would be considered a different item, so it should be
moved as Foo_2.  Similarly, if we move Foo to the archive, then it and
all sub-pages/attachments would be moved.  A later page Foo:Bar would
still be a subpage of a new Foo page, so moving Bar to the archive
should ideally create Foo_2:Bar.

But the question is, what happens if after moving Foo:Bar to the
archive, I then decide to also move Foo to the archive.  In this case,
Foo should be moved in such a way that it is the parent of the old
Foo:Bar that was moved to the archive.

Similarly, what happens if we create a page Foo, then move it to the
archive.  Then create another page Foo, then move it to the archive. 
Then create a page Foo, a subpage Bar, then move Foo:Bar to the archive,
then move Foo to the archive.

1st move -> Archive:Foo
2nd move -> Archive:Foo.2
3rd move -> Archive:Foo:Bar or Archive:Foo.2:Bar or Achivive:Foo.3:Bar?
(where Archive:Foo.3 isn't a page just an empty namespace)
4th move -> Arhive:Foo.3 or Archive:Foo.4

Perhaps, for situations when such conflicts exist a dialog could be
presented to ask the user.  In the 3rd move, the user could select to
move Bar to Archive:Foo, Archive:Foo.2 or to create a new namespace
Archive:Foo.3.  In the 4th move, the user could select to overwrite an
existing Archive:Foo, to move it to the empty Archive:Foo.3 (if Bar was
moved here in the third move) or to create a new namespace page.

Another idea may be for each archive to be timestamped in a manor of
speaking, such as 201508171422
However, each directory is just called Foo and displayed as Foo in the
GUI.  So the directory structure would be:

Archive/
    Foo@xxxxxxxxxxxxxxxx
    Foo/
        Bar@xxxxxxxxxxxxxxxx

Then later if we archive another Foo, it would be placed as
Archive/Foo@xxxxxxxxxxxxxxxx.  If it had any sub-pages, they would be
archived similarly:

Archive/
    Foo@xxxxxxxxxxxxxxxx
    Foo@xxxxxxxxxxxxxxxx
    Foo/
        Bar@xxxxxxxxxxxxxxxx
        Bar@xxxxxxxxxxxxxxxx
        Baz@xxxxxxxxxxxxxxxx

Then later if we archive another Foo:Bar, it would be placed under
Archive/Foo.  The GUI would need to respond specially when selecting to
view items in the archive.  Each time an item in the archive is selected
a list would need to be seen to show/select which time stamp to view. 
Links would work the same.  That is Archive:Foo link to Bar would link
to Archive:Foo:Bar, and if there is more than one, show the first one
(or one with a matching time stamp of the current selection) with a list
to select the others.

The above idea may work fine, but what about attachments.  If I move a
page Foo:Bar which has an attachment "image.jpg".  We could perhaps
rename the attachments, but this may break if two attachments somehow
depend on each other to have specific file names.  We could have
specific attachment directories which contain attachment files only, not
actual pages:
 

Archive/
    Foo@xxxxxxxxxxxxxxxx
    Foo@xxxxxxxxxxxxxxxx
    Foo@201508231832/ (only attachments, not sub-pages)
    Foo/
        Bar@xxxxxxxxxxxxxxxx
        Bar@201508171422/ (only attachments, not subpages)
        Bar@xxxxxxxxxxxxxxxx
        Baz@xxxxxxxxxxxxxxxx


Brian Allen Vanderburg II


On 09/13/2015 03:47 AM, Jaap Karssenberg wrote:
> I have been drafting a blueprint how archive should work before.
>
> Personally I keep a big "Archive" namespace and move stuff there to
> get it out of the way.One thing that bothers me now is that all these
> archive results show up as well in page name completion and when
> searching. Ideally I would want this namespace to be special in the
> sense that I can search it, but it is not included in the default
> results. ( Maybe in the search dialog towards the bottom there could
> be a button "show X more results from the archive". )
>
> One question though: to make it fully automatic we should also think
> about name conflicts. E.g. if I archive "Foo" it moves to
> "Archive:Foo" - if I later create a new page "Foo" and archive it
> again, I can not move it to "Archive:Foo" again. We can solve this
> e.g. by appending a timestamp of the archivation.
>
> More difficult is the case where we archived "Foo" before, so
> "Archive:Foo" exists, but now we created a new page "Foo:Bar" and
> archive that one. Do we move it to the existing "Archive:Foo", do we
> create a new "Archive:Foo_1", or do we just move "Bar" to the toplevel
> in the archive creating "Archive:Bar".
>
> Which of these options does most justice to the history in which these
> pages are archived ?
>
> Regards,
>
> Jaap
>
>
>
>
> On Fri, Sep 11, 2015 at 9:46 AM, Vlastimil Ott <linux@xxxxxxxxxx
> <mailto:linux@xxxxxxxxxx>> wrote:
>
>     Dne 19.8.2015 v 13:45 Jaap Karssenberg napsal(a):
>
>
>         For delete, I don't see the use case to have a zim specific
>         trash can.
>         But if you think more about archiving, I can see a potential
>         feature there.
>
>
>     +1 Would be nice
>
>     --
>
>     Vlastimil Ott
>
>     www.e-ott.info <http://www.e-ott.info>
>     www.opensourceblog.cz <http://www.opensourceblog.cz>
>     @vlastimilott
>
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~zim-wiki
>     <https://launchpad.net/%7Ezim-wiki>
>     Post to     : zim-wiki@xxxxxxxxxxxxxxxxxxx
>     <mailto:zim-wiki@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~zim-wiki
>     <https://launchpad.net/%7Ezim-wiki>
>     More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~zim-wiki
> Post to     : zim-wiki@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: OpenPGP digital signature