Quantcast

Suggestion: GRAMPS db conversion util?

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

Suggestion: GRAMPS db conversion util?

jdebert
Sometimes people get caught out by an unexpected version upgrade of
GRAMPS (like with OpenSuSE) and find their db is incompatible. It's a
lot of trouble to reinstall an older version to export and back up the
db and there is the risk of running afoul of dependencies which could
make db upgrading far more difficult if not impossible.

How much trouble would it be to put together a standalone util to
convert between GRAMPS db formats, for upgrading to newer GRAMPS
version or downgrading to older versions, or for import/export?

Such a util would likely be smaller than GRAMPS and quite a bit more
convenient. if it could convert all GRAMPS db versions It would be a
very useful thing to have and save people from having to maintain
different versions of GRAMPS. Having import and export capabilities
would make it even more useful.

Would this be worth proposing as a feature request?

jd
--


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

DS Blank
On Sun, Sep 9, 2012 at 7:58 AM, j debert <[hidden email]> wrote:

> Sometimes people get caught out by an unexpected version upgrade of
> GRAMPS (like with OpenSuSE) and find their db is incompatible. It's a
> lot of trouble to reinstall an older version to export and back up the
> db and there is the risk of running afoul of dependencies which could
> make db upgrading far more difficult if not impossible.
>
> How much trouble would it be to put together a standalone util to
> convert between GRAMPS db formats, for upgrading to newer GRAMPS
> version or downgrading to older versions, or for import/export?
>
> Such a util would likely be smaller than GRAMPS and quite a bit more
> convenient. if it could convert all GRAMPS db versions It would be a
> very useful thing to have and save people from having to maintain
> different versions of GRAMPS. Having import and export capabilities
> would make it even more useful.
>
> Would this be worth proposing as a feature request?

jd,

I think that the problem you identify is a very valid issue, but
perhaps your solution is not the best.

I think it would be a fine idea to make a feature request that capture
the essence of the problem: Need to make a backup of a DB which is
already out of date with the current version of Gramps.

For example, it might be able to at least "dump" the database in a
low-level format, or in the new "struct" format for Gramps 4.0. Then
you have some assurance that you do indeed have a backup before
beginning the irreversible upgrade procedure. Or maybe your solution
would work, if we kept older versions of the export code around. There
may in fact be a feature request related to this already. In any
event, a feature is the way to go so we don't forget.

-Doug

> jd
> --
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users

------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

Benny Malengier
And a utility is actually already present. Here on Ubuntu I can install db-util 4.7, 4.8 and 5.1 from the default repository.
Problem is that only one will be compiled into python, so from python we can only work with one.

Although we don't have the best database backend in terms of binary compatibility, if you would wait 10 years, I don't think many other formats would work all that good.

Personally, I would like somebody to create a virtual box image of OS's with older vesion of Gramps installed. Like that, we would have a tool in 10 years time to open an old database somebody has lying around.

Benny

2012/9/9 Doug Blank <[hidden email]>
On Sun, Sep 9, 2012 at 7:58 AM, j debert <[hidden email]> wrote:
> Sometimes people get caught out by an unexpected version upgrade of
> GRAMPS (like with OpenSuSE) and find their db is incompatible. It's a
> lot of trouble to reinstall an older version to export and back up the
> db and there is the risk of running afoul of dependencies which could
> make db upgrading far more difficult if not impossible.
>
> How much trouble would it be to put together a standalone util to
> convert between GRAMPS db formats, for upgrading to newer GRAMPS
> version or downgrading to older versions, or for import/export?
>
> Such a util would likely be smaller than GRAMPS and quite a bit more
> convenient. if it could convert all GRAMPS db versions It would be a
> very useful thing to have and save people from having to maintain
> different versions of GRAMPS. Having import and export capabilities
> would make it even more useful.
>
> Would this be worth proposing as a feature request?

jd,

I think that the problem you identify is a very valid issue, but
perhaps your solution is not the best.

I think it would be a fine idea to make a feature request that capture
the essence of the problem: Need to make a backup of a DB which is
already out of date with the current version of Gramps.

For example, it might be able to at least "dump" the database in a
low-level format, or in the new "struct" format for Gramps 4.0. Then
you have some assurance that you do indeed have a backup before
beginning the irreversible upgrade procedure. Or maybe your solution
would work, if we kept older versions of the export code around. There
may in fact be a feature request related to this already. In any
event, a feature is the way to go so we don't forget.

-Doug

> jd
> --
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users

------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

James Sherring
I think that there are a couple of important principles here that are worth elaborating. My two cents below.

Principle/Use case "Gramps continues to work after all automated updates":
A user has Gramps installed on an active system, but doesn't use Gramps for some time (possibly years), with multiple Gramps software updates during that time. Regardless of 
any automated software updates, a user should be able to open their active Gramps database. The principle is that automated software updates must not cause something to stop working.

Solution option 1:
I think that an automated software upgrade should also upgrade the working DB. I suppose Gramps doesn't do that? There will be an issue with shared software Vs user DBs.
Gramps should also support opening and converting at least the most recent previous database format.

Solution option 2:
Gramps must support opening all old database formats. This may require considerable complexity after multiple major database structure changes.


Principle/Use case "Gramps can open any valid back-up/XML export":
If I create a backup or XML export from Gramps, then I should be guaranteed that anyone can open this file forever - or at least for the lifetime of the Gramps project :)
I may take a break from family history for a number of years. Or I may die and leave my research as digital media that is accessed after decades.
The alternative is to always export as GEDCOMS for long-term backups (which is probably sensible anyway on a periodic basis).
Is the Gramps file itself the research artifact, or just a tool to produce other artifacts to be preserved? I think the former.


It would be useful to have a project stance on these - any comments?

James

------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

Benny Malengier


2012/9/10 James Sherring <[hidden email]>
I think that there are a couple of important principles here that are worth elaborating. My two cents below.

Principle/Use case "Gramps continues to work after all automated updates":
A user has Gramps installed on an active system, but doesn't use Gramps for some time (possibly years), with multiple Gramps software updates during that time. Regardless of 
any automated software updates, a user should be able to open their active Gramps database. The principle is that automated software updates must not cause something to stop working.

Solution option 1:
I think that an automated software upgrade should also upgrade the working DB. I suppose Gramps doesn't do that? There will be an issue with shared software Vs user DBs.
Gramps should also support opening and converting at least the most recent previous database format.

Solution option 2:
Gramps must support opening all old database formats. This may require considerable complexity after multiple major database structure changes.

This works in Gramps withing what we support.
For example:
To open a gramps 1.x db file, you need gramps 2.1.x
To open a 2.x db file, you need gramps 3.0.x

So current gramps 3.4.x supports the db format since 3.0. It can normally import _all_ xml .gramps file.

The main problem for a community project like gramps is testing that this really keeps working.

I am not aware of people who could not open an old gramps file or database, on questions to the users list, they have always been helped. People did loose information due to deleting files or disk corruption, which is not something we can fix. To avoid the problems of people deleting needed database files, we deprecated the old .grdb format and hide in current Gramps where the database is stored. The reasoning here is that this should make people wonder where their data is stored, so as to know how to backup. Or they look in the menu of gramps and see the backup entry, or they look up the documentation and see there is a database directory they can back up.

If people enter a lot of information, and don't ask the above question, I don't think a program can do anything to have the data save over long time periods. The OS would be a better solution then, like time machine on OS X.


Principle/Use case "Gramps can open any valid back-up/XML export":
If I create a backup or XML export from Gramps, then I should be guaranteed that anyone can open this file forever - or at least for the lifetime of the Gramps project :)
I may take a break from family history for a number of years. Or I may die and leave my research as digital media that is accessed after decades.
The alternative is to always export as GEDCOMS for long-term backups (which is probably sensible anyway on a periodic basis).
Is the Gramps file itself the research artifact, or just a tool to produce other artifacts to be preserved? I think the former.

Xml keeps on working. You can download old xml from the code repository to verify this.
The .gramps is the thing to keep. We don't store custom tags with information not in the GEDCOM standard but stored in gramps, paf and others do, as there is no guarantee anyway they can be read by anybody else than gramps.

Benny


It would be useful to have a project stance on these - any comments?

James


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

jdebert
In reply to this post by DS Blank
On 09/09/2012 09:02 AM, Doug Blank wrote:

> On Sun, Sep 9, 2012 at 7:58 AM, j debert <[hidden email]> wrote:
>> Sometimes people get caught out by an unexpected version upgrade of
>> GRAMPS (like with OpenSuSE) and find their db is incompatible. It's a
>> lot of trouble to reinstall an older version to export and back up the
>> db and there is the risk of running afoul of dependencies which could
>> make db upgrading far more difficult if not impossible.
>>
>> How much trouble would it be to put together a standalone util to
>> convert between GRAMPS db formats, for upgrading to newer GRAMPS
>> version or downgrading to older versions, or for import/export?
>>
>> Such a util would likely be smaller than GRAMPS and quite a bit more
>> convenient. if it could convert all GRAMPS db versions It would be a
>> very useful thing to have and save people from having to maintain
>> different versions of GRAMPS. Having import and export capabilities
>> would make it even more useful.
>>
>> Would this be worth proposing as a feature request?
>
> jd,
>
> I think that the problem you identify is a very valid issue, but
> perhaps your solution is not the best.

It isn't the best, naturally. It is an idea that needs development.

>
> I think it would be a fine idea to make a feature request that capture
> the essence of the problem: Need to make a backup of a DB which is
> already out of date with the current version of Gramps.
>

It's more than that. There will be occasions when people will acquire
data in old, obsolete db formats. At present there isn't a way to use
that data in GRAMPS. It has to be converted to the current db version
before it is usable. Presently, it seems that this will require
multiple processes especially when the db is several versions behind.
The intention is to make the process simple.

For instance, if the db is in the version used by GRAMPS 1, it cannot
be upgraded, imported to GRAMPS 4 without being first exported to a
format that GRAMPS 2 can read and import, and which in turn must be
used to again export the db to a format readble by GRAMPS 3, et
cetera. You would need to use GRAMPS 1, GRAMPS 2 , GRAMPS 3 at least
in order to get the db into a format readable by GRAMPS 4. The process
is risky and may not be possible depending on the versions of python,
et cetera.

Acquiring data from foreign formats is an afterthought, actually, but
fits within the general idea of db conversion and upgrading.

> For example, it might be able to at least "dump" the database in a
> low-level format, or in the new "struct" format for Gramps 4.0. Then
> you have some assurance that you do indeed have a backup before
> beginning the irreversible upgrade procedure. Or maybe your solution
> would work, if we kept older versions of the export code around. There
> may in fact be a feature request related to this already. In any
> event, a feature is the way to go so we don't forget.
>

What I had in mind was basically an import-export process that would
preserve the data in some basic, generic format during the conversion
process. Instead of direct conversion, there would be intermediate
steps. I think this would help ensure a reliable and accurate
conversion and support import and export from various other formats.

A utility that takes several simple steps for the process would be
easier and likely safer for data than one using a single complex step.

I haven't completed the concept of the utility. I doubt it will be
complete, actually, but I think it needs more development before
submitting.

jd
--


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

jdebert
In reply to this post by Benny Malengier
On 09/09/2012 01:46 PM, Benny Malengier wrote:
> And a utility is actually already present. Here on Ubuntu I can install
> db-util 4.7, 4.8 and 5.1 from the default repository.
> Problem is that only one will be compiled into python, so from python we
> can only work with one.

I wonder how easy it is for GRAMPS users to use? One of the features I
think it should have is that it should be easy for anyone to use.

If I recall correctly there can only be one db version in use at any
given time. That pretty much makes conversion very difficult if not
impossible, and it would increase he risk of errors because of all the
work required.
>
> Although we don't have the best database backend in terms of binary
> compatibility, if you would wait 10 years, I don't think many other formats
> would work all that good.

I don't expect the database format or code to be stable or static
anytime soon. There's always room for improvement and there's always
more data to be found and included.
>
> Personally, I would like somebody to create a virtual box image of OS's
> with older vesion of Gramps installed. Like that, we would have a tool in
> 10 years time to open an old database somebody has lying around.
>

That would work pretty well and it would avoid dependency problems but
it would not simplify the process. I suspect much grumbling would
ensue if people had to upgrade their db by that process.

jd
--


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

jerome
In reply to this post by Benny Malengier
Note for fun, I have play with a pseudo 'Gramps XML validator'!

During documentation updates (rng, dtd, etc ...), we often missed a
small section or so. Not very important, because there is no real XML
validation, except a matching header/namespace on XML import.

Well, I looked at tools/scripts (without java) for a quick Gramps XML
handling/parsing. I have used simple XML flat tables in the past (before
using Gramps; ie. it was before Gramps 0.8...). By using old 'reflexes'
and python basics, I got some python code. :)

See:
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/branches/gramps34/contrib/lxml/

It works for validating a Gramps XML file in pure python and some 3rd
party tools (common one).

I made an update for the new database model (3.3.x to 3.4.x), but I did
not want to get both versions ... The logical way is to support the last
one. I suppose it is possible to check all Gramps XML files according to
their related namespaces, but it means a lot of tests for a simple usage.

Note, I used custom .dtd and .rng files because of some specific custom
types: http://www.gramps-project.org/bugs/view.php?id=5264



Le 10/09/2012 09:47, Benny Malengier a écrit :

>
>
> 2012/9/10 James Sherring <[hidden email]
> <mailto:[hidden email]>>
>
>     I think that there are a couple of important principles here that
>     are worth elaborating. My two cents below.
>
>     Principle/Use case "Gramps continues to work after all automated
>     updates":
>     A user has Gramps installed on an active system, but doesn't use
>     Gramps for some time (possibly years), with multiple Gramps software
>     updates during that time. Regardless of
>     any automated software updates, a user should be able to open their
>     active Gramps database. The principle is that automated software
>     updates must not cause something to stop working.
>
>     Solution option 1:
>     I think that an automated software upgrade should also upgrade the
>     working DB. I suppose Gramps doesn't do that? There will be an issue
>     with shared software Vs user DBs.
>     Gramps should also support opening and converting at least the most
>     recent previous database format.
>
>
>     Solution option 2:
>     Gramps must support opening all old database formats. This may
>     require considerable complexity after multiple major database
>     structure changes.
>
>
> This works in Gramps withing what we support.
> For example:
> To open a gramps 1.x db file, you need gramps 2.1.x
> To open a 2.x db file, you need gramps 3.0.x
>
> So current gramps 3.4.x supports the db format since 3.0. It can
> normally import _all_ xml .gramps file.
>
> The main problem for a community project like gramps is testing that
> this really keeps working.
>
> I am not aware of people who could not open an old gramps file or
> database, on questions to the users list, they have always been helped.
> People did loose information due to deleting files or disk corruption,
> which is not something we can fix. To avoid the problems of people
> deleting needed database files, we deprecated the old .grdb format and
> hide in current Gramps where the database is stored. The reasoning here
> is that this should make people wonder where their data is stored, so as
> to know how to backup. Or they look in the menu of gramps and see the
> backup entry, or they look up the documentation and see there is a
> database directory they can back up.
>
> If people enter a lot of information, and don't ask the above question,
> I don't think a program can do anything to have the data save over long
> time periods. The OS would be a better solution then, like time machine
> on OS X.
>
>
>     Principle/Use case "Gramps can open any valid back-up/XML export":
>     If I create a backup or XML export from Gramps, then I should be
>     guaranteed that anyone can open this file forever - or at least for
>     the lifetime of the Gramps project :)
>     I may take a break from family history for a number of years. Or I
>     may die and leave my research as digital media that is accessed
>     after decades.
>     The alternative is to always export as GEDCOMS for long-term backups
>     (which is probably sensible anyway on a periodic basis).
>     Is the Gramps file itself the research artifact, or just a tool to
>     produce other artifacts to be preserved? I think the former.
>
>
> Xml keeps on working. You can download old xml from the code repository
> to verify this.
> The .gramps is the thing to keep. We don't store custom tags with
> information not in the GEDCOM standard but stored in gramps, paf and
> others do, as there is no guarantee anyway they can be read by anybody
> else than gramps.
>
> Benny
>
>
>
>     It would be useful to have a project stance on these - any comments?
>
>     James
>
>
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

jdebert
In reply to this post by James Sherring
On 09/09/2012 03:16 PM, James Sherring wrote:

> I think that there are a couple of important principles here that are worth
> elaborating. My two cents below.
>
> Principle/Use case "Gramps continues to work after all automated updates":
> A user has Gramps installed on an active system, but doesn't use Gramps for
> some time (possibly years), with multiple Gramps software updates during
> that time. Regardless of
> any automated software updates, a user should be able to open their active
> Gramps database. The principle is that automated software updates must not
> cause something to stop working.
>
> Solution option 1:
> I think that an automated software upgrade should also upgrade the working
> DB. I suppose Gramps doesn't do that? There will be an issue with shared
> software Vs user DBs.
> Gramps should also support opening and converting at least the most recent
> previous database format.

Automatically upgrading data formats on app updates is extremely
risky. One mistake, one small error by a developer, packager,
installer, or anything else could wipe out or damage a lot of other
people's data. Personally, were I a developer, packager, etc., I would
not want to be responsible for losing other people's data.


>
> Solution option 2:
> Gramps must support opening all old database formats. This may require
> considerable complexity after multiple major database structure changes.

I fear that this would turn GRAMPS into one of those massively
monolithic behemoths that would be too big to be practical or useful.
I really would prefer not to have gigbyte-sized applications. That's a
lot like having a kitchen with simply everything in it, including a
bathtub and toilet. :)

>
>
> Principle/Use case "Gramps can open any valid back-up/XML export":
> If I create a backup or XML export from Gramps, then I should be guaranteed
> that anyone can open this file forever - or at least for the lifetime of
> the Gramps project :)
> I may take a break from family history for a number of years. Or I may die
> and leave my research as digital media that is accessed after decades.
> The alternative is to always export as GEDCOMS for long-term backups (which
> is probably sensible anyway on a periodic basis).
> Is the Gramps file itself the research artifact, or just a tool to produce
> other artifacts to be preserved? I think the former.
>

GRAMPS is not exactly a stable app. At least not in terms of sticking
to one design or methodology. As such it should not be constrained to
maintain data in any particular format because that would be a major
stumbling block to further improvements and innovation.

Part of the reasoning behind having a separate utility is to leave
GRAMPS free to develop and improve, while providing a more convenient
means to upgrade, update and convert db formats across all versions.

I would not want GRAMPS to have the means itself to do this because it
makes GRAMPS increasingly complicated and difficult to maintain. I
think GRAMPS is already more than big enough and this functionality is
not something that is going to be used enough to justify being
incorporated into GRAMPS.

jd
--


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestion: GRAMPS db conversion util?

jdebert
In reply to this post by jerome
Thanks for the feedback and critique everyone.

I have a much clearer idea of what kind of feature request to do.

I'm going to first test the feasability of what I have in mind and
to make sure I can properly communicate the idea.

jd
--


------------------------------------------------------------------------------
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Loading...