Re: Roadmap to 1.0

[Daniel Falk <f-spot mbx zapto org>]

Brian J. Murrell wrote:
> On Tue, 2009-05-12 at 12:00 -0400, Daniel Falk wrote:
>   
> > Probably true, though even designing a spec for that is probably going 
> > to be difficult.
> >     
>
> <snip>
> > - Working in remote locations over the internet
> >     
>
> Hrm.  I'm not sure what you are imagining here, but whatever network
> protocols are being used in a LAN to access the shared photos and
> database should work over the Internet.  If you are talking about
> "securely" doing it over the Internet, then again, I strongly disagree
> that this is the same as the multi-user feature.  It's again, yet a
> completely different feature.
>
>   

Again, if you're going to allow for a good multi-user experience, you're 
almost certainly going to have to redesign key parts of f-spot.  I have 
not read details of any design discussion, but I assume it must have 
taken place or will take place.  While you're right that the features 
I've described are different, they are related in that the redesign 
should probably take all those possibilities into account in order to 
avoid further disruptive redesign.  Perhaps not though. 

I'm just saying that I think this feature is part of a larger problem.  
Believe me though, I agree that it would be an awesome thing to solve.  
I would just hate for it to get solved in a shortsighted way.

> > - Working in the same database as another user simultaneously
> >     
>
> Yes.  This would need to be handled.  No idea what sqlite's abilities
> are in this respect, whether it allows simultaneous access by multiple
> users and/or provides data locking.  This might be a good reason why a
> real (for a value of real that includes real multiple user access)
> database like MySQL might need to be optionally supported.
>   

It's not just the database.  I would think you would want to be able to 
notify other clients that things have changed...basically have an 
event-managing component.  The UI would then respond to those events...

> > I question whether hiding the photos away is the full intent of f-spot.  
> > If that were the case it would make it simpler if the photos were put in 
> > the same place as the database, perhaps even in the database.  It would 
> > simplify migration and diminish the possibility of people doing things 
> > like deleting pictures outside of f-spot.
> >     
>
> Yeah.  I have thought about that too.  But I don't know if many
> databases (sqlite especially) really handle blobs all that well.
>   

Again, that's only one option.  It would certainly be a cleaner 
implementation to put the photos in the same place as the photo db, and 
hidden from the user.  That is, if trawling is not the intent.

> > No.  If I had to guess the intent of F-spot based on how it's coded 
> > today, I'd say that you are definitely meant to be able to trawl through 
> > the structure.
> >     
>
> I agree you _can_.  I don't necessarily agree you should or are meant
> to.
>   

Again, if you're not meant to, the cleaner thing to do is to hide the 
photos away in or near the database.  It's only a guess based on the way 
things work that they wanted the user to have flexibility here.

> > And I, for one, like it that way.  Let's assume you're right--that if 
> > you need to trawl through the structure then f-spot is missing a 
> > feature.  Well fine.  But f-spot will always be missing features.  It 
> > just always will.  There will always be some cool thing that program X 
> > is doing but hasn't been integrated into f-spot yet.
> >     
>
> That's what export is for.
>   
> But I don't really care to argue this point of whether one should be
> able to or not.  I don't really care about it.
>   

Alright, I won't argue it further either.  But then I can also not 
accept your claim that one shouldn't be expected to browse one's own 
photos in nautilus etc.  Unless you could offer something more appealing 
than having the user export to a temporary location in order to do 
things with an actual file.