[Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment

[Simon Cropper (Botanicus Australia Pty Ltd)]

Cèsar,

Thanks for the information.

It is very good that you are addressing this issue and I look forward to 
the release of Version 2.

I recently looked at the published road map for the project but this is 
out of date. Can you estimate when the next version will be released - 
1, 6, 12 months?

Cheers Simon

Simon Cropper
Botanicus Australia Pty Ltd
PO Box 160, Sunshine, Victoria 3020.
P: 9311 5822. M: 041 830 3437.
mailto: scropper at botanicusaustralia.com.au 
<mailto:scropper at botanicusaustralia.com.au>
web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>


On 21/01/2010 12:22 AM, Cèsar Ordiñana wrote:
> Hi Simon,
>
> First of all, thanks for all your feedback, suggestions and errors
> reported.
>
> I'm deeply involved in the development of the gvSIG 2.0, so I would like
> to explain what is being done in relation to your points 6 and 8.
>
> One of the main changes in gvSIG 2.0 is a complete design and
> implementation of the data access library. Knowing the problems of
> previous versions, like the ones you have highlighted, we added resource
> management to the library implementation.
>
> This way, if the user opens many layers in the same or different views
> from the same file, or even many table documents, we know they share the
> same file. The resource management service also locks write access to a
> resource, so two different layers (in the same gvSIG instance) can't
> write a file at the same time, but one after the other.
>
> So now we have the basic tools to be able to solve some of those
> problems, but still have to do some work to translate that knowledge to
> the application level. Things like:
>
> - If you finish editing a layer, refresh other layers from the same file.
> - Warn the user that he's trying to edit a layer which is being edited
> in another view.
> - ...
>
> I'm not sure how much development effort we will be able to spend in
> this problem, but I think in gvSIG 2.0 we will be able to handle those
> cases more gracefully, at least for the most regular ones.
>
> All of this for the single gvSIG instance with many layers/views of the
> same file scenario. For the scenario of many gvSIG instances or other
> applications opening the same file, we could use file locking at the
> system level. But I hope this to be a more unusual case, as I don't
> think we will be able to work on it for the gvSIG 2.0 release.
>
> Regards,
>
>