Quantcast

Proposal for default media directory

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal for default media directory

DS Blank
Developers,

I'm thinking of a "default folder for media" for a few uses:

1) It would be handy for importing a backup with media to
automatically move them to a centralized folder

2) If we had the ability to drag-and-drop media onto Gramps, this is
where the file would go

3) On a web-based gramps, this would be the folder for importing media
(rather than in the file system in general).

4) a known folder as an option for media management organization

5) could be used as the base path for relative media paths

I imagine that one could define the folder (in Preferences) using
variables such as ${user}, ${grampshome}, ${version}, etc. For
example, "${grampshome}/media/${user}" would put such media in
"/home/dblank/.gramps/media/dblank/".

Does this sound like the best way to handle these needs? Any comments/concerns?

-Doug

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

John Ralls-2

On May 6, 2012, at 7:36 AM, Doug Blank wrote:

> Developers,
>
> I'm thinking of a "default folder for media" for a few uses:
>
> 1) It would be handy for importing a backup with media to
> automatically move them to a centralized folder
>
> 2) If we had the ability to drag-and-drop media onto Gramps, this is
> where the file would go
>
> 3) On a web-based gramps, this would be the folder for importing media
> (rather than in the file system in general).
>
> 4) a known folder as an option for media management organization
>
> 5) could be used as the base path for relative media paths
>
> I imagine that one could define the folder (in Preferences) using
> variables such as ${user}, ${grampshome}, ${version}, etc. For
> example, "${grampshome}/media/${user}" would put such media in
> "/home/dblank/.gramps/media/dblank/".
>
> Does this sound like the best way to handle these needs? Any comments/concerns?

+1!

Especially the bit about it being a base for relative paths.

Regards,
John Ralls


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Nick Hall-6
In reply to this post by DS Blank
Doug,

These seem like good ideas to me.

How does this change what we have at the moment though?  Why not just
use the existing relative media path for these new uses?

Do you plan to store the "default folder for media" in the database or
ini file?  I can see that the path variables that you propose might make
more sense if it was stored in the database.

Nick.


On 06/05/12 15:36, Doug Blank wrote:

> Developers,
>
> I'm thinking of a "default folder for media" for a few uses:
>
> 1) It would be handy for importing a backup with media to
> automatically move them to a centralized folder
>
> 2) If we had the ability to drag-and-drop media onto Gramps, this is
> where the file would go
>
> 3) On a web-based gramps, this would be the folder for importing media
> (rather than in the file system in general).
>
> 4) a known folder as an option for media management organization
>
> 5) could be used as the base path for relative media paths
>
> I imagine that one could define the folder (in Preferences) using
> variables such as ${user}, ${grampshome}, ${version}, etc. For
> example, "${grampshome}/media/${user}" would put such media in
> "/home/dblank/.gramps/media/dblank/".
>
> Does this sound like the best way to handle these needs? Any comments/concerns?
>
> -Doug
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
On Sat, May 12, 2012 at 12:52 PM, Nick Hall <[hidden email]> wrote:
> Doug,
>
> These seem like good ideas to me.
>
> How does this change what we have at the moment though?  Why not just
> use the existing relative media path for these new uses?

Thanks, Nick, for these insights!

I think you are right that the existing relative media path could be
used for all of these. I was thinking the same thing, once I had tried
some code and saw that we could change the meaning of the relative
path.

> Do you plan to store the "default folder for media" in the database or
> ini file?  I can see that the path variables that you propose might make
> more sense if it was stored in the database.

There was only one reservation I had about combining all of these uses
together, but keeping the relative media path with the database would
solve that issue. (I was worried about having different versions of a
picture, and those backups. But it could be the case that you could
have your media path (and actual media) directly associated with the
database.)

So, here is an amended proposal:

1) Move the default media path to the database. This will require it
to be stored in XML, and on disk. There are two bits of text
associated with a database: bdbversion.txt and name.txt. We could
combine all text into a single file (xml or ini). Or we could create a
third text file. (If we create an xml/ini file for the database, I
could think of other things that could go there, BTW.)

2) Should we change the name from "relative media path" to "default
media directory"? Tools for changing the path would describe it as
being "relative to the default media directory".

3) Media dropped onto Gramps will be copied to this directory. (Could
have a popup allowing a choice as well.)

4) Add tool to allow moving of media to this default media folder.

5) Web imports would put incoming media here.

6) For new databases and imports that don't store the relative media
path, should we set the initial value to the current value, ie user's
home? That will keep the current meaning working as it currently does.
(The web import would have a different initial value.)

7) In addition to adding ${user} and ${grampshome} variables to be
used in this path, we could also include ${database} for allowing
media based on the gramps database folder, eg
/home/user/.gramps/user/45234.

-Doug

> Nick.
>
>
> On 06/05/12 15:36, Doug Blank wrote:
>> Developers,
>>
>> I'm thinking of a "default folder for media" for a few uses:
>>
>> 1) It would be handy for importing a backup with media to
>> automatically move them to a centralized folder
>>
>> 2) If we had the ability to drag-and-drop media onto Gramps, this is
>> where the file would go
>>
>> 3) On a web-based gramps, this would be the folder for importing media
>> (rather than in the file system in general).
>>
>> 4) a known folder as an option for media management organization
>>
>> 5) could be used as the base path for relative media paths
>>
>> I imagine that one could define the folder (in Preferences) using
>> variables such as ${user}, ${grampshome}, ${version}, etc. For
>> example, "${grampshome}/media/${user}" would put such media in
>> "/home/dblank/.gramps/media/dblank/".
>>
>> Does this sound like the best way to handle these needs? Any comments/concerns?
>>
>> -Doug
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
Oh, mediapath is already stored in the database, in the metadata:

    def get_mediapath(self):
        """Return the default media path of the database."""
        if self.metadata is not None:
            return self.metadata.get('mediapath', None)
        return None

So, nothing needs actually be added to the db. Items 2 through 7 are
still valid.

-Doug

On Sun, May 13, 2012 at 8:45 AM, Doug Blank <[hidden email]> wrote:

> On Sat, May 12, 2012 at 12:52 PM, Nick Hall <[hidden email]> wrote:
>> Doug,
>>
>> These seem like good ideas to me.
>>
>> How does this change what we have at the moment though?  Why not just
>> use the existing relative media path for these new uses?
>
> Thanks, Nick, for these insights!
>
> I think you are right that the existing relative media path could be
> used for all of these. I was thinking the same thing, once I had tried
> some code and saw that we could change the meaning of the relative
> path.
>
>> Do you plan to store the "default folder for media" in the database or
>> ini file?  I can see that the path variables that you propose might make
>> more sense if it was stored in the database.
>
> There was only one reservation I had about combining all of these uses
> together, but keeping the relative media path with the database would
> solve that issue. (I was worried about having different versions of a
> picture, and those backups. But it could be the case that you could
> have your media path (and actual media) directly associated with the
> database.)
>
> So, here is an amended proposal:
>
> 1) Move the default media path to the database. This will require it
> to be stored in XML, and on disk. There are two bits of text
> associated with a database: bdbversion.txt and name.txt. We could
> combine all text into a single file (xml or ini). Or we could create a
> third text file. (If we create an xml/ini file for the database, I
> could think of other things that could go there, BTW.)
>
> 2) Should we change the name from "relative media path" to "default
> media directory"? Tools for changing the path would describe it as
> being "relative to the default media directory".
>
> 3) Media dropped onto Gramps will be copied to this directory. (Could
> have a popup allowing a choice as well.)
>
> 4) Add tool to allow moving of media to this default media folder.
>
> 5) Web imports would put incoming media here.
>
> 6) For new databases and imports that don't store the relative media
> path, should we set the initial value to the current value, ie user's
> home? That will keep the current meaning working as it currently does.
> (The web import would have a different initial value.)
>
> 7) In addition to adding ${user} and ${grampshome} variables to be
> used in this path, we could also include ${database} for allowing
> media based on the gramps database folder, eg
> /home/user/.gramps/user/45234.
>
> -Doug
>
>> Nick.
>>
>>
>> On 06/05/12 15:36, Doug Blank wrote:
>>> Developers,
>>>
>>> I'm thinking of a "default folder for media" for a few uses:
>>>
>>> 1) It would be handy for importing a backup with media to
>>> automatically move them to a centralized folder
>>>
>>> 2) If we had the ability to drag-and-drop media onto Gramps, this is
>>> where the file would go
>>>
>>> 3) On a web-based gramps, this would be the folder for importing media
>>> (rather than in the file system in general).
>>>
>>> 4) a known folder as an option for media management organization
>>>
>>> 5) could be used as the base path for relative media paths
>>>
>>> I imagine that one could define the folder (in Preferences) using
>>> variables such as ${user}, ${grampshome}, ${version}, etc. For
>>> example, "${grampshome}/media/${user}" would put such media in
>>> "/home/dblank/.gramps/media/dblank/".
>>>
>>> Does this sound like the best way to handle these needs? Any comments/concerns?
>>>
>>> -Doug
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Gramps-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

jerome
About web storage and display, I tried to list/store mediapaths into one HTML file (local use), like a simple gallery index. It was a mixture between existing code and common usage (relative and/or absolute paths).

   # Gramps XML

    if two.tag == '{http://gramps-project.org/xml/1.5.0/}mediapath':
  mediapath = two.text
    else:
  mediapath = ''

 ...

    if three.tag == '{http://gramps-project.org/xml/1.5.0/}file':
        thumbs.append(three.items())

    src = (list(thumbs[i])[0])[1]

 ...

    # relative and absolute paths
       
  src = os.path.join(mediapath, src)
 
        if src.startswith("/"):
     continue
  else:
     src = os.path.join(const.USER_HOME, src)
 
  # only images
 
  if mime.startswith("image"):
     thumb = ThumbNails.get_thumbnail_path(str(src), mtype=None, rectangle=None)
     self.text += Html('img', src=str(thumb), mtype=str(mime))


My main problem was the copy/storage for around 500Mo/Mb of media objects... So, the simple way was to re-use thumbnails generated by Gramps!

For an external storage or online images maybe a thumbnails generator might be a solution?

If so, the current thumbnails directory is not the right place for this!
ie. local copy should be only removed by the user, should be an other directory for external media objects

To get something for retrieving a copy.
See also feature requests #3599, #5248, #5430

http://www.gramps-project.org/bugs/view.php?id=3599
http://www.gramps-project.org/bugs/view.php?id=5248
http://www.gramps-project.org/bugs/view.php?id=5430


Jérôme


--- En date de : Dim 13.5.12, Doug Blank <[hidden email]> a écrit :

> De: Doug Blank <[hidden email]>
> Objet: Re: [Gramps-devel] Proposal for default media directory
> À: "Nick Hall" <[hidden email]>
> Cc: [hidden email]
> Date: Dimanche 13 mai 2012, 18h36
> Oh, mediapath is already stored in
> the database, in the metadata:
>
>     def get_mediapath(self):
>         """Return the default media path
> of the database."""
>         if self.metadata is not None:
>             return
> self.metadata.get('mediapath', None)
>         return None
>
> So, nothing needs actually be added to the db. Items 2
> through 7 are
> still valid.
>
> -Doug
>
> On Sun, May 13, 2012 at 8:45 AM, Doug Blank <[hidden email]>
> wrote:
> > On Sat, May 12, 2012 at 12:52 PM, Nick Hall <[hidden email]>
> wrote:
> >> Doug,
> >>
> >> These seem like good ideas to me.
> >>
> >> How does this change what we have at the moment
> though?  Why not just
> >> use the existing relative media path for these new
> uses?
> >
> > Thanks, Nick, for these insights!
> >
> > I think you are right that the existing relative media
> path could be
> > used for all of these. I was thinking the same thing,
> once I had tried
> > some code and saw that we could change the meaning of
> the relative
> > path.
> >
> >> Do you plan to store the "default folder for media"
> in the database or
> >> ini file?  I can see that the path variables that
> you propose might make
> >> more sense if it was stored in the database.
> >
> > There was only one reservation I had about combining
> all of these uses
> > together, but keeping the relative media path with the
> database would
> > solve that issue. (I was worried about having different
> versions of a
> > picture, and those backups. But it could be the case
> that you could
> > have your media path (and actual media) directly
> associated with the
> > database.)
> >
> > So, here is an amended proposal:
> >
> > 1) Move the default media path to the database. This
> will require it
> > to be stored in XML, and on disk. There are two bits of
> text
> > associated with a database: bdbversion.txt and
> name.txt. We could
> > combine all text into a single file (xml or ini). Or we
> could create a
> > third text file. (If we create an xml/ini file for the
> database, I
> > could think of other things that could go there, BTW.)
> >
> > 2) Should we change the name from "relative media path"
> to "default
> > media directory"? Tools for changing the path would
> describe it as
> > being "relative to the default media directory".
> >
> > 3) Media dropped onto Gramps will be copied to this
> directory. (Could
> > have a popup allowing a choice as well.)
> >
> > 4) Add tool to allow moving of media to this default
> media folder.
> >
> > 5) Web imports would put incoming media here.
> >
> > 6) For new databases and imports that don't store the
> relative media
> > path, should we set the initial value to the current
> value, ie user's
> > home? That will keep the current meaning working as it
> currently does.
> > (The web import would have a different initial value.)
> >
> > 7) In addition to adding ${user} and ${grampshome}
> variables to be
> > used in this path, we could also include ${database}
> for allowing
> > media based on the gramps database folder, eg
> > /home/user/.gramps/user/45234.
> >
> > -Doug
> >
> >> Nick.
> >>
> >>
> >> On 06/05/12 15:36, Doug Blank wrote:
> >>> Developers,
> >>>
> >>> I'm thinking of a "default folder for media"
> for a few uses:
> >>>
> >>> 1) It would be handy for importing a backup
> with media to
> >>> automatically move them to a centralized
> folder
> >>>
> >>> 2) If we had the ability to drag-and-drop media
> onto Gramps, this is
> >>> where the file would go
> >>>
> >>> 3) On a web-based gramps, this would be the
> folder for importing media
> >>> (rather than in the file system in general).
> >>>
> >>> 4) a known folder as an option for media
> management organization
> >>>
> >>> 5) could be used as the base path for relative
> media paths
> >>>
> >>> I imagine that one could define the folder (in
> Preferences) using
> >>> variables such as ${user}, ${grampshome},
> ${version}, etc. For
> >>> example, "${grampshome}/media/${user}" would
> put such media in
> >>> "/home/dblank/.gramps/media/dblank/".
> >>>
> >>> Does this sound like the best way to handle
> these needs? Any comments/concerns?
> >>>
> >>> -Doug
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Live Security Virtual Conference
> >>> Exclusive live event will cover all the ways
> today's security and
> >>> threat landscape has changed and how IT
> managers can respond. Discussions
> >>> will include endpoint security, mobile security
> and the latest in malware
> >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >>>
> _______________________________________________
> >>> Gramps-devel mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>>
> >>>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways
> today's security and
> >> threat landscape has changed and how IT managers
> can respond. Discussions
> >> will include endpoint security, mobile security and
> the latest in malware
> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and
> threat landscape has changed and how IT managers can
> respond. Discussions
> will include endpoint security, mobile security and the
> latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Michael Tiernan
In reply to this post by DS Blank
----- Original Message -----
> Cc: [hidden email]
> Sent: Sunday, May 13, 2012 8:45:16 AM
> Subject: Re: [Gramps-devel] Proposal for default media directory

> 7) In addition to adding ${user} and ${grampshome} variables to be
> used in this path, we could also include ${database} for allowing
> media based on the gramps database folder, eg
> /home/user/.gramps/user/45234.

As a systems administrator, I'd like to take this opportunity to respectfully point out that the use of a hidden directory for the "root" of the gramps tree is not appropriate. If the desire for a directory with a few rc files is needed, that's fine and a hidden directory is what one would use but the hiding of *all* the gramps data and associated files is not in keeping with best (or even good) practices.

The use of "~/.rcfile" or "~/.rcdir" type files/directories is so that any application can quickly, logically, and consistently locate the root of the user's space (i.e. $HOME) and load the minimum information required to then locate all other aspects of its environment(s).

I would encourage the use of a separate directory as ${grampsHome} and continue to use "~/.gramps" as the value of ${grampsRoot} (or if you want "${grampsEnv}") but if "grampsHome" is not set it should get the default value of "~/Gramps" and *not* a hidden location.

It is from these few settings that all other paths needed would be derived. If you create a media path ${grampsMedia} then its default value(s) is built from ${grampsHome} and probably/possibly includes a value for "${treeName}" or some such detail. (This also allows the user to change this as needed/desired.)

Thanks for everyone's time.
--
    << MCT >>   Michael C Tiernan.
    Is God a performance artist?
    http://www.linkedin.com/in/mtiernan

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
On Mon, May 14, 2012 at 7:57 AM, Michael C Tiernan
<[hidden email]> wrote:

> ----- Original Message -----
>> Cc: [hidden email]
>> Sent: Sunday, May 13, 2012 8:45:16 AM
>> Subject: Re: [Gramps-devel] Proposal for default media directory
>
>> 7) In addition to adding ${user} and ${grampshome} variables to be
>> used in this path, we could also include ${database} for allowing
>> media based on the gramps database folder, eg
>> /home/user/.gramps/user/45234.
>
> As a systems administrator, I'd like to take this opportunity to respectfully point out that the use of a hidden directory for the "root" of the gramps tree is not appropriate. If the desire for a directory with a few rc files is needed, that's fine and a hidden directory is what one would use but the hiding of *all* the gramps data and associated files is not in keeping with best (or even good) practices.
>
> The use of "~/.rcfile" or "~/.rcdir" type files/directories is so that any application can quickly, logically, and consistently locate the root of the user's space (i.e. $HOME) and load the minimum information required to then locate all other aspects of its environment(s).
>
> I would encourage the use of a separate directory as ${grampsHome} and continue to use "~/.gramps" as the value of ${grampsRoot} (or if you want "${grampsEnv}") but if "grampsHome" is not set it should get the default value of "~/Gramps" and *not* a hidden location.
>
> It is from these few settings that all other paths needed would be derived. If you create a media path ${grampsMedia} then its default value(s) is built from ${grampsHome} and probably/possibly includes a value for "${treeName}" or some such detail. (This also allows the user to change this as needed/desired.)
>
> Thanks for everyone's time.

Michael,

I agree! But, if you really want to make this happen, you should make
a feature request, list out the pros and cons, necessary changes,
migration issues, and any other impact. Then you, or someone else can
propose a minimal patch where it can be discussed, and hopefully
applied. Initially, having a grampshome be a config setting, set to
the same value as grampsroot, with a discussion of what would be
where, would be a start.

Thanks!

-Doug

> --
>    << MCT >>   Michael C Tiernan.
>    Is God a performance artist?
>    http://www.linkedin.com/in/mtiernan
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
In reply to this post by jerome
On Mon, May 14, 2012 at 3:21 AM, jerome <[hidden email]> wrote:

> About web storage and display, I tried to list/store mediapaths into one HTML file (local use), like a simple gallery index. It was a mixture between existing code and common usage (relative and/or absolute paths).
>
>   # Gramps XML
>
>    if two.tag == '{http://gramps-project.org/xml/1.5.0/}mediapath':
>         mediapath = two.text
>    else:
>         mediapath = ''
>
>  ...
>
>    if three.tag == '{http://gramps-project.org/xml/1.5.0/}file':
>        thumbs.append(three.items())
>
>    src = (list(thumbs[i])[0])[1]
>
>  ...
>
>    # relative and absolute paths
>
>        src = os.path.join(mediapath, src)
>
>        if src.startswith("/"):
>            continue
>        else:
>            src = os.path.join(const.USER_HOME, src)
>
>        # only images
>
>        if mime.startswith("image"):
>            thumb = ThumbNails.get_thumbnail_path(str(src), mtype=None, rectangle=None)
>            self.text += Html('img', src=str(thumb), mtype=str(mime))
>
>
> My main problem was the copy/storage for around 500Mo/Mb of media objects... So, the simple way was to re-use thumbnails generated by Gramps!
>
> For an external storage or online images maybe a thumbnails generator might be a solution?
>
> If so, the current thumbnails directory is not the right place for this!
> ie. local copy should be only removed by the user, should be an other directory for external media objects

I think, at least initially, the thumbnail directory and management
should be treated as a separate issue. These are gramps-managed
resources. It seems like a web-based Gramps (or other addon/use)
should use the gramps thumbnail API, rather than attempting to use
them outside of the defined gramps code interface. But perhaps you
just want to add to the interface (for example, with a
create_thumbnail("all")). Is that what you mean by a "thumbnails
generator"?

> To get something for retrieving a copy.
> See also feature requests #3599, #5248, #5430
>
> http://www.gramps-project.org/bugs/view.php?id=3599
> http://www.gramps-project.org/bugs/view.php?id=5248
> http://www.gramps-project.org/bugs/view.php?id=5430

Thanks for those related requests! I think there is a separate
decision about whether Gramps should:

1) support URLs for stored media (dynamically retrieve URLs inside
Gramps-gtk, and on web) Maybe convert all media to URIs (which would
include file://, http://, ftp://, etc)
2) Automatically make a local copy of retrieved URL media at import

Currently, I don't think we do either. But this is a separate
discussion from the "default media folder" which we need first.

-Doug

>
> Jérôme
>
>
> --- En date de : Dim 13.5.12, Doug Blank <[hidden email]> a écrit :
>
>> De: Doug Blank <[hidden email]>
>> Objet: Re: [Gramps-devel] Proposal for default media directory
>> À: "Nick Hall" <[hidden email]>
>> Cc: [hidden email]
>> Date: Dimanche 13 mai 2012, 18h36
>> Oh, mediapath is already stored in
>> the database, in the metadata:
>>
>>     def get_mediapath(self):
>>         """Return the default media path
>> of the database."""
>>         if self.metadata is not None:
>>             return
>> self.metadata.get('mediapath', None)
>>         return None
>>
>> So, nothing needs actually be added to the db. Items 2
>> through 7 are
>> still valid.
>>
>> -Doug
>>
>> On Sun, May 13, 2012 at 8:45 AM, Doug Blank <[hidden email]>
>> wrote:
>> > On Sat, May 12, 2012 at 12:52 PM, Nick Hall <[hidden email]>
>> wrote:
>> >> Doug,
>> >>
>> >> These seem like good ideas to me.
>> >>
>> >> How does this change what we have at the moment
>> though?  Why not just
>> >> use the existing relative media path for these new
>> uses?
>> >
>> > Thanks, Nick, for these insights!
>> >
>> > I think you are right that the existing relative media
>> path could be
>> > used for all of these. I was thinking the same thing,
>> once I had tried
>> > some code and saw that we could change the meaning of
>> the relative
>> > path.
>> >
>> >> Do you plan to store the "default folder for media"
>> in the database or
>> >> ini file?  I can see that the path variables that
>> you propose might make
>> >> more sense if it was stored in the database.
>> >
>> > There was only one reservation I had about combining
>> all of these uses
>> > together, but keeping the relative media path with the
>> database would
>> > solve that issue. (I was worried about having different
>> versions of a
>> > picture, and those backups. But it could be the case
>> that you could
>> > have your media path (and actual media) directly
>> associated with the
>> > database.)
>> >
>> > So, here is an amended proposal:
>> >
>> > 1) Move the default media path to the database. This
>> will require it
>> > to be stored in XML, and on disk. There are two bits of
>> text
>> > associated with a database: bdbversion.txt and
>> name.txt. We could
>> > combine all text into a single file (xml or ini). Or we
>> could create a
>> > third text file. (If we create an xml/ini file for the
>> database, I
>> > could think of other things that could go there, BTW.)
>> >
>> > 2) Should we change the name from "relative media path"
>> to "default
>> > media directory"? Tools for changing the path would
>> describe it as
>> > being "relative to the default media directory".
>> >
>> > 3) Media dropped onto Gramps will be copied to this
>> directory. (Could
>> > have a popup allowing a choice as well.)
>> >
>> > 4) Add tool to allow moving of media to this default
>> media folder.
>> >
>> > 5) Web imports would put incoming media here.
>> >
>> > 6) For new databases and imports that don't store the
>> relative media
>> > path, should we set the initial value to the current
>> value, ie user's
>> > home? That will keep the current meaning working as it
>> currently does.
>> > (The web import would have a different initial value.)
>> >
>> > 7) In addition to adding ${user} and ${grampshome}
>> variables to be
>> > used in this path, we could also include ${database}
>> for allowing
>> > media based on the gramps database folder, eg
>> > /home/user/.gramps/user/45234.
>> >
>> > -Doug
>> >
>> >> Nick.
>> >>
>> >>
>> >> On 06/05/12 15:36, Doug Blank wrote:
>> >>> Developers,
>> >>>
>> >>> I'm thinking of a "default folder for media"
>> for a few uses:
>> >>>
>> >>> 1) It would be handy for importing a backup
>> with media to
>> >>> automatically move them to a centralized
>> folder
>> >>>
>> >>> 2) If we had the ability to drag-and-drop media
>> onto Gramps, this is
>> >>> where the file would go
>> >>>
>> >>> 3) On a web-based gramps, this would be the
>> folder for importing media
>> >>> (rather than in the file system in general).
>> >>>
>> >>> 4) a known folder as an option for media
>> management organization
>> >>>
>> >>> 5) could be used as the base path for relative
>> media paths
>> >>>
>> >>> I imagine that one could define the folder (in
>> Preferences) using
>> >>> variables such as ${user}, ${grampshome},
>> ${version}, etc. For
>> >>> example, "${grampshome}/media/${user}" would
>> put such media in
>> >>> "/home/dblank/.gramps/media/dblank/".
>> >>>
>> >>> Does this sound like the best way to handle
>> these needs? Any comments/concerns?
>> >>>
>> >>> -Doug
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Live Security Virtual Conference
>> >>> Exclusive live event will cover all the ways
>> today's security and
>> >>> threat landscape has changed and how IT
>> managers can respond. Discussions
>> >>> will include endpoint security, mobile security
>> and the latest in malware
>> >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >>>
>> _______________________________________________
>> >>> Gramps-devel mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Live Security Virtual Conference
>> >> Exclusive live event will cover all the ways
>> today's security and
>> >> threat landscape has changed and how IT managers
>> can respond. Discussions
>> >> will include endpoint security, mobile security and
>> the latest in malware
>> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >> _______________________________________________
>> >> Gramps-devel mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's
>> security and
>> threat landscape has changed and how IT managers can
>> respond. Discussions
>> will include endpoint security, mobile security and the
>> latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Michael Tiernan
In reply to this post by DS Blank
----- Original Message -----
> But, if you really want to make this happen, you should make
> a feature request,

Me and my big mouth!  :)

I will create a feature request for this but am going to have to resort to depending on those much more experienced with the internals of Gramps in deciding the changes that will be required. (I made an effort to not be an armchair quarterback but I felt that the opinion should be expressed.)

I am *not* at all an experienced enough developer (in python) to even begin to approach a problem like this.

With all that said, yes, I'll post my email to the bugtracker with a clear note saying I am not qualified to work on it.

Again, thanks for everyone's time.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

jerome
In reply to this post by DS Blank
> I think, at least initially, the thumbnail directory and
> management
> should be treated as a separate issue. These are
> gramps-managed
> resources. It seems like a web-based Gramps (or other
> addon/use)
> should use the gramps thumbnail API, rather than attempting
> to use
> them outside of the defined gramps code interface. But
> perhaps you
> just want to add to the interface (for example, with a
> create_thumbnail("all")). Is that what you mean by a
> "thumbnails
> generator"?
>

Yes and no !
Ignoring handles and DB, I do not really use thumbnail API (gramps) ... :-[

Here, thumbnail API has been used for getting paths according to media object (image)! Then to use 'GrampsDisplay.url(html)'...
I suppose this can be displayed via HTML view too, within Gramps!

Sure, if we were able to generate thumbnails into a separate directory via thumbnail API, then it might be a complete Gramps code/sequence. But as thumbnails have been already generated for my family trees and because I just want to do this for my local use I do not need more (no copy of existing local files).

True, this other feature could be for a thumbnails generator for web-based Gramps or new content (no local thumbnails files generated by loaded family trees).

I only wanted to illustrate that the current feature for handling default media directory is good for a local use if we think on file:// protocol.
Change for online support also means to find a solution for thumbnails.
I suppose it was what you were asking for.


Jérôme


> >> _______________________________________________
> >> Gramps-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Benny Malengier
In reply to this post by Michael Tiernan
The problem we have is that the database files are sensitive to being moved. Therefore the database as something hidden is a  way to try to achieve users not touching those files.
If users export data, or need a directory for the media, it should be a normal directory somewhere in their home directory.

You are right however, it is not ideal. To avoid a broken database is however the most important. Main problem with the hidden directory seems to be that people forget to include it in their backup. We hoped that people would wonder 'where does gramps store my family trees', and based on that add .gramps to the backup scheme, but you find here and there a user that looses everything because they did not do so.

For my own use of linux, I hate directories of programs visible in my home dir, I only want directories that I create, and nothing from programs. Yes, I don't use a Desktop dir, only the home. So I'm ok with the current situation :-)

Benny

2012/5/14 Michael C Tiernan <[hidden email]>
----- Original Message -----
> But, if you really want to make this happen, you should make
> a feature request,

Me and my big mouth!  :)

I will create a feature request for this but am going to have to resort to depending on those much more experienced with the internals of Gramps in deciding the changes that will be required. (I made an effort to not be an armchair quarterback but I felt that the opinion should be expressed.)

I am *not* at all an experienced enough developer (in python) to even begin to approach a problem like this.

With all that said, yes, I'll post my email to the bugtracker with a clear note saying I am not qualified to work on it.

Again, thanks for everyone's time.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Michael Tiernan
----- Original Message -----
> From: "Benny Malengier" <[hidden email]>
> Sent: Tuesday, May 15, 2012 9:17:13 AM

> The problem we have is that the database files are sensitive to being moved.
They're sensitive period, not just to being moved.
"Security by obscurity" is a fallacy many people fall into.

While I understand your points, let me point out that the proposed change(s) do not conflict with your style of operation but that *not* changing conflicts with good operating procedures and generally accepted practices.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
In reply to this post by Benny Malengier
On Tue, May 15, 2012 at 9:17 AM, Benny Malengier
<[hidden email]> wrote:
> The problem we have is that the database files are sensitive to being moved.
> Therefore the database as something hidden is a  way to try to achieve users
> not touching those files.
> If users export data, or need a directory for the media, it should be a
> normal directory somewhere in their home directory.
>
> You are right however, it is not ideal. To avoid a broken database is
> however the most important.

Benny,

I appreciate your use (and as Michael suggests, your use wouldn't
change). But I would argue that avoiding breaking a database is second
to making sure that it is back-upped. If you move or rename something,
you can always put it back or restore. But if you do not backup
.gramps, then you are in big trouble no matter what. As one who has
done this, I know that it probably happens more than we know :(

Does anyone object to separating path items into general "data" and
"config" categories (which would initially--for now--have the same
values, and remain where they are)? Users can then set the "data" to
wherever they wish.

-Doug

> Main problem with the hidden directory seems to
> be that people forget to include it in their backup. We hoped that people
> would wonder 'where does gramps store my family trees', and based on that
> add .gramps to the backup scheme, but you find here and there a user that
> looses everything because they did not do so.
>
> For my own use of linux, I hate directories of programs visible in my home
> dir, I only want directories that I create, and nothing from programs. Yes,
> I don't use a Desktop dir, only the home. So I'm ok with the current
> situation :-)
>
> Benny
>
>
> 2012/5/14 Michael C Tiernan <[hidden email]>
>>
>> ----- Original Message -----
>> > But, if you really want to make this happen, you should make
>> > a feature request,
>>
>> Me and my big mouth!  :)
>>
>> I will create a feature request for this but am going to have to resort to
>> depending on those much more experienced with the internals of Gramps in
>> deciding the changes that will be required. (I made an effort to not be an
>> armchair quarterback but I felt that the opinion should be expressed.)
>>
>> I am *not* at all an experienced enough developer (in python) to even
>> begin to approach a problem like this.
>>
>> With all that said, yes, I'll post my email to the bugtracker with a clear
>> note saying I am not qualified to work on it.
>>
>> Again, thanks for everyone's time.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Brian Matherly
>I appreciate your use (and as Michael suggests, your use wouldn't

>change). But I would argue that avoiding breaking a database is second
>to making sure that it is back-upped. If you move or rename something,
>you can always put it back or restore. But if you do not backup
>.gramps, then you are in big trouble no matter what. As one who has
>done this, I know that it probably happens more than we know :(


I would actually argue that the .gramps directory should *not* be backed up because it gives a false sense of security. The database files hidden in the .gramps directory are not portable and are not guaranteed to be able to restored on a new system. The only safe (and supported) backup method is to export the database to a Gramps XML file. All Gramps users should get in the habit of creating frequent XML exports and putting them in a safe backup location. This can be done manually, or automated from the command line.


Sorry to make a tangent here - but I don't like to see bad practice propagated.

http://www.gramps-project.org/wiki/index.php?title=How_to_make_a_backup


~BM


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

John Ralls-2
In reply to this post by Benny Malengier

On May 15, 2012, at 6:17 AM, Benny Malengier wrote:

> The problem we have is that the database files are sensitive to being moved. Therefore the database as something hidden is a  way to try to achieve users not touching those files.
> If users export data, or need a directory for the media, it should be a normal directory somewhere in their home directory.
>
> You are right however, it is not ideal. To avoid a broken database is however the most important. Main problem with the hidden directory seems to be that people forget to include it in their backup. We hoped that people would wonder 'where does gramps store my family trees', and based on that add .gramps to the backup scheme, but you find here and there a user that looses everything because they did not do so.
>
> For my own use of linux, I hate directories of programs visible in my home dir, I only want directories that I create, and nothing from programs. Yes, I don't use a Desktop dir, only the home. So I'm ok with the current situation :-)
>

Do you mean that the individual files are sensitive to being moved, or whole directories? My experience with BDB (including with Gramps) is that as long as the contents of a DBEnv directory stay together, moving the directory isn't a problem. Moving some files out of the directory will certainly break the database, but that's true of every multi-file DBMS I've used, and it's not common practice to use hidden directories for DBMS data files.

Backing up is indeed important, but I think most sysadmins point their backup program at /home and let it do its thing recursively. Unless the program is very badly written (or the sysadmin is an idiot and puts e.g. "- .*" in a .rsync file)  it will pick up the hidden files and directories without further ado. That said, I think most users are rather unlike you and prefer to have their program data in a visible directory.  Do you also put your correspondence and spreadsheets in hidden directories?

Anyway, the location of databases is a bit of a strawman, because we have a preference that allows the user to put it somewhere separate from $GRAMPSHOME. What about the private temp directory (which never seems to get cleared out) or the map-tile cache (ditto)? There's no good reason to back those up. They belong in /tmp so that the regular cleanup routines can get to them. The plugin code belongs in $PYTHONHOME/site-packages, but I understand you don't want to make the user authenticate for sudo access to put it there, though it's a bit of a security bust not to.

Regards,
John Ralls


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

Michael Tiernan
In reply to this post by Brian Matherly
----- Original Message -----
> I don't like to see bad practice propagated.

Hey hey there, none of that. I don't want to be out of a job.  ;)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
In reply to this post by Brian Matherly
On Tue, May 15, 2012 at 11:41 AM, Brian Matherly
<[hidden email]> wrote:

>>I appreciate your use (and as Michael suggests, your use wouldn't
>
>>change). But I would argue that avoiding breaking a database is second
>>to making sure that it is back-upped. If you move or rename something,
>>you can always put it back or restore. But if you do not backup
>>.gramps, then you are in big trouble no matter what. As one who has
>>done this, I know that it probably happens more than we know :(
>
>
> I would actually argue that the .gramps directory should *not* be backed up because it gives a false sense of security. The database files hidden in the .gramps directory are not portable and are not guaranteed to be able to restored on a new system. The only safe (and supported) backup method is to export the database to a Gramps XML file. All Gramps users should get in the habit of creating frequent XML exports and putting them in a safe backup location. This can be done manually, or automated from the command line.
>

Well, there are a whole lot of different kinds of data in the .gramps
folder. Report styles, plugins, ToDo Gramplet contents, variety of
.ini files, etc. I can't really imagine someone backing those up as
"bad practice". But, yes, one should know exactly what they are doing
when using Gramps, and how these files are used, and their
limitations.

But I also can imagine someone backing up the .gramps/grampsdb folder
too. Of course, this is not guaranteed to be useful, but without
anything else, it is a nice something to fall back to.

I can also imagine a day in the not too distant future where the
database files are portable and cross-platform. I'm working on that...

-Doug

> Sorry to make a tangent here - but I don't like to see bad practice propagated.
>
> http://www.gramps-project.org/wiki/index.php?title=How_to_make_a_backup
>
>
> ~BM
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

DS Blank
On Tue, May 15, 2012 at 12:45 PM, Doug Blank <[hidden email]> wrote:

> On Tue, May 15, 2012 at 11:41 AM, Brian Matherly
> <[hidden email]> wrote:
>>>I appreciate your use (and as Michael suggests, your use wouldn't
>>
>>>change). But I would argue that avoiding breaking a database is second
>>>to making sure that it is back-upped. If you move or rename something,
>>>you can always put it back or restore. But if you do not backup
>>>.gramps, then you are in big trouble no matter what. As one who has
>>>done this, I know that it probably happens more than we know :(
>>
>>
>> I would actually argue that the .gramps directory should *not* be backed up because it gives a false sense of security. The database files hidden in the .gramps directory are not portable and are not guaranteed to be able to restored on a new system. The only safe (and supported) backup method is to export the database to a Gramps XML file. All Gramps users should get in the habit of creating frequent XML exports and putting them in a safe backup location. This can be done manually, or automated from the command line.
>>
>
> Well, there are a whole lot of different kinds of data in the .gramps
> folder. Report styles, plugins, ToDo Gramplet contents, variety of
> .ini files, etc. I can't really imagine someone backing those up as
> "bad practice". But, yes, one should know exactly what they are doing
> when using Gramps, and how these files are used, and their
> limitations.
>
> But I also can imagine someone backing up the .gramps/grampsdb folder
> too. Of course, this is not guaranteed to be useful, but without
> anything else, it is a nice something to fall back to.

BTW, the CSV archives made by Gramps (Family Tree Manager -> Archive)
are also stored in the .gramps/grampsdb/*/ folders. Another reason why
one might want to back these up.

-Doug

> I can also imagine a day in the not too distant future where the
> database files are portable and cross-platform. I'm working on that...
>
> -Doug
>
>> Sorry to make a tangent here - but I don't like to see bad practice propagated.
>>
>> http://www.gramps-project.org/wiki/index.php?title=How_to_make_a_backup
>>
>>
>> ~BM
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for default media directory

jerome
> BTW, the CSV archives made by Gramps (Family Tree Manager
> -> Archive)
> are also stored in the .gramps/grampsdb/*/ folders.

Lapsus!

I suppose you thought on RCS (Concurrent Versions System) and write CSV?


--- En date de : Mar 15.5.12, Doug Blank <[hidden email]> a écrit :

> De: Doug Blank <[hidden email]>
> Objet: Re: [Gramps-devel] Proposal for default media directory
> À: "Brian Matherly" <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Date: Mardi 15 mai 2012, 19h12
> On Tue, May 15, 2012 at 12:45 PM,
> Doug Blank <[hidden email]>
> wrote:
> > On Tue, May 15, 2012 at 11:41 AM, Brian Matherly
> > <[hidden email]>
> wrote:
> >>>I appreciate your use (and as Michael suggests,
> your use wouldn't
> >>
> >>>change). But I would argue that avoiding
> breaking a database is second
> >>>to making sure that it is back-upped. If you
> move or rename something,
> >>>you can always put it back or restore. But if
> you do not backup
> >>>.gramps, then you are in big trouble no matter
> what. As one who has
> >>>done this, I know that it probably happens more
> than we know :(
> >>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...