RE: How are glom applications distributed?

[Murray Cumming <murrayc murrayc com>]

On Tue, 2010-03-16 at 17:52 +0100, Stroobandt Serge wrote:
> -----Original Message-----
> From: Murray Cumming
> Sent: 16 March 2010 16:51
> To: Stroobandt Serge
> Cc: glom-devel-list gnome org
> Subject: Re: How are glom applications distributed?
>
> On Tue, 2010-03-16 at 16:45 +0100, Stroobandt Serge wrote:
> > > How are glom applications distributed?
>
> > Should I assume that you want all users to share the same database, not
> copies of it?
>
> Actually, I have both use cases.

If you want to distribute copies, then you can use the self-hosting
option, distributing the data along with the .glom file. Unfortunately
the files seem to be huge for Postgres (though we have not investigated
that yet). For embedded use, it's possible to use SQLite instead, though
it isn't thoroughly tested/supported.

> So, if I understand it correctly the user interface layout is contained in the .glom file.

Yes, and some of the information about the data structure that can't
easily be discovered otherwise.

> From a maintenance perspective & IMHO, it would be better to limit .glom files to be a kind of key or 
> pointer to the database where the layout is stored.

Yes, I think it would be useful to store the glom file's XML somewhere
in the database itself and it wouldn't be too difficult. Patches and
funding are welcome, of course, though it's not a priority for my own
time.

> This would still not be a web UI application

I think it's important, and I hope to eventually get that done.

>  -which I do not necessarily need-. However, changes to the user interface layout would immediately 
> propagate to the operator users.

As they would if you just shared access to one .glom file.

> So there you have again a good reason to store files in the DB ;-)
>
> But don't worry; this takes not away from still considering glom as a quick application development 
> platform. However, on the long run, above suggestion is something that I really think should need to be 
> considered.


-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com