<gicmo> I am looking at the acl patch at the moment ..
<gicmo> http://bugzilla.gnome.org/attachment.cgi?id=54627&action=view
<gicmo> did you have a look at it yet ..
<alex> Oh, there is a new one?
<gicmo> yeah ..
<gicmo> hmm its a better approach then the first one I guess .. but there are a few things I wonder about ..
<gicmo> I guess I would suggest moving all that posix acl backend stuff out of libgnomevfs into modules .. since its file method sepcific
<gicmo> and have a new "virtual" module functions that will create the GnomeVFSFileACL struct on a gnome_vfs_file_acl_new () call, and set the (acl) backend pointer there ..
<gicmo> I also suggest omitting the File from all those structs and functions .. not sure why its there ..
<gicmo> because we dont need different backends for e.g. webdav .. because for webdav and smb there is only one way of setting the acl info in the first place ...
<gicmo> its only for file:// to do that ..
<alex> do_get_file_info_from_handle is racy, isn't there a way to set the acl by fd?
<gicmo> hmm 
<alex> + if ((strcasecmp (parts[0], "d") == 0) ||
<alex> +     (strcasecmp (parts[0], "default") == 0))
<alex> thats locale specific, need to use the g_ascii stuff
<alex> + else if ((strcasecmp (kind, "g") == 0) || 
<alex> +   (strcasecmp (kind, "group") == 0)) {
<alex> I wonder why he supports both?
<gicmo> yeah .. not sure ..
<alex> seems better to just pick one instead of sprinkling the code with multiple alternatives
<alex> especially since the really common values user/group/etc need to be shared amongst all backends
<gicmo> yes ..
<gicmo> I guess group instead of g is more descriptive
<alex> so, why support g?
<gicmo> yeah ... we should remove that ...
<alex> +static const gchar *  
<alex> +_get_support (GnomeVFSFileACLBackendPosix *aclb)
<alex> +{
<alex> + return "d:ugo:rwx";
<alex> +}
<alex> +
<alex> then that seems to say it only supports u/g/o, not user/group/other
<gicmo> extern int acl_set_fd(int fd, acl_t acl);
<gicmo> there is a fd based version
<alex> in fact, with such an api you can't specify a multi-char name
<gicmo> ohh yeah right ..
<alex> I don't like the extremely stringbased api
<alex> i mean, strings are fine for extensibility, as names
<alex> but passing in structure as string, i.e. the a:b:c thing is strange
<alex> it means we have to parse
<gicmo> yeah ...
<gicmo> on the other hand it will be quite difficult to find a good, felixble set of predfined stuff for all backends
<alex> +GnomeVFSResult
<alex> +gnome_vfs_file_acl_backend_read (GnomeVFSFileACLBackend *aclb, const gchar *filepath)
<alex> why is that in the generic api???
<alex> I'm just saying that instead of passing a "a:b:c" string you can pass three strings, to avoid having to parse.
<gicmo> yeah yeah .. that's what I mean with my statement of moving such stuff into modules and make it file backend specific
<gicmo> ahhh ok ok ... yeah that makes sense ..
<alex> +static GnomeVFSResult 
<alex> +_commit (GnomeVFSFileACLBackendPosix *aclb)
<alex> The ACL object is tied to a filename/uri
<alex> thats pretty strange...
<gicmo> yeah .. I dont think we should do that ..
<alex> You should be able to use an ACL object on many backends imho
<alex> i.e. the ACL object should be a storage
<gicmo> exactly
<alex> and the backend is what takes the ACL object and puts it in the filesystem
<gicmo> yeah .. and let the backend then handle the actual implementation
<gicmo> yes ..
<alex> i.e. the backend is part of the normal module api
<gicmo> so we wouldnt need that acl backend stuff in libgnomevfs at all ..
<alex> no
<alex> Just GnomeVFSFileACL, which should work for all backends
<gicmo> maybe before explaining that bunch of stuff to the guy (I have him in my icq list, btw), I could use his patch as a basis and make the modifications we have in mind myself .. what do you think ..
<gicmo> I have uni from 13:30 to 15:00 but after that I have plenty of time today
<alex> at least if module->supports_acl (module, acl) == TRUE or something like that
<alex> That would be great
<gicmo> integrating with the file info struct is a good idea, what do you think?
<alex> Yeah
<gicmo> or better have seperate calls for it .. like gnome_vfs_set_acl, gnome_vfs_get_acl ?
<alex> No, it fits better as a file info thing
<gicmo> I think having it in the info struct is fine ..
<alex> I'm not sure the API supports everything needed though
<gicmo> ok ok .. so we wouldnt even need too much extra module calls ..
<alex> like deny rules
<gicmo> I guess it would be a good idea to integrate it as we want it (maybe commit it on an acl branch) and then try to integrate it in the specific backend modules .. to see what problems are there with this api
<alex> yeah
<alex> sounds good
<gicmo> I can do the webdav part .. and maybe natan can do the smb method thingy ... we can write him a mail and ask
<gicmo> sweet .. I am going to start now then .. (I will be away from 13:00 to 15:00 though) but continue after that
<alex> +gnome_vfs_file_acl_add (GnomeVFSFileACL *acl, const gchar *acl_str)
<alex> should be more liek
<alex> acl_add(Acl *acl, char *kind, char *id, char *value, gboolean default)
<alex> to avoid the parsing
<alex> i'm not sure that is enough for everything though
<alex> and maybe value doesn't have to be a string
<alex> how would you do a deny rule for group foo with that?
<alex> and what exactly is the default thing?
<gicmo> heh, good question ... I am reading through webdav acls atm .. which gives me headaches to be honest ..
<alex> gnome_vfs_file_acl (acl, "user", "123", ACL_READ|ACL_WRITE)
<alex> might be better
<gicmo> yeah ... sounds good ..
<alex> although then its hard to extend the ACL_READ stuff...
<gicmo> hmmm .. 
<gicmo> heh, I dont want to have to design the UI for that .. seriously
<gicmo> its going to be very hard if you dont wanna make it ueber-cryptic
<alex> http://bugzilla.gnome.org/show_bug.cgi?id=62835#c7
<alex> that has some interesting availible things
<gicmo> GNOME_VFS_ACL_PERMISSION_LOOKUP
<gicmo> GNOME_VFS_ACL_PERMISSION_LOCK,
<gicmo> GNOME_VFS_ACL_PERMISSION_A
<gicmo> haha
<gicmo> PERMISSION_A
<gicmo> yeah right ..
<alex> i guess its something that AFS lets the sysadmin choose
<gicmo> GNOME_VFS_ACL_TYPE_POSSITIVE,
<gicmo> GNOME_VFS_ACL_TYPE_NEGATIVE
<gicmo> interesting ....
<alex> yeah
<alex> also, that has GNOME_VFS_ACL_TAG_DEFAULT_GROUP and GNOME_VFS_ACL_TAG_GROUP instead of a default flag
<alex> seems better
<alex> more generalizable
<alex> maybe
<gicmo> I thinks so too ..
<alex> anyway, it would be great if you could try to come up with a better starting point
<gicmo> hmm but its a whole lof of constants .. we maybe need guint64 if we wanna integrate that into gnome_vfs_file_acl (acl, "user", "123", FLAGS)
<alex> gicmo: Or use strings...
<alex> i guess what you really want is an enum
<alex> hmm
<gicmo> yeah .. but I guess we would at least neet some "hey module, what kind of stuff to you support" module call .. right
<alex> or is it?
<gicmo> I mean to let the UI know what one can do and not ...
<alex> do you want acl_add(acl, "user", "123", ["read", "write"]) or acl_add(acl, "user", "123", "read"); acl_add(acl, "user", "123", "write");
<alex> yeah, there has to be some way to check
<alex> I was hoping we could have a general API for most standard file things that all backends supported
<alex> that e.g. the nautilus ui could use
<gicmo> yeah .. which would make it ueber-easy for _xfer () acl preserving
<gicmo> yeah and for the UI of course ..
<alex> and then you'd have string extensions for other things
<alex> and you'd have to do extra code for that in nautilus
<alex> some sort of plugin maybe
<alex> or just if (support_foo) spaghetti
<gicmo> yeah ...
<gicmo> haha
<gicmo> but yeah ..
<alex> maybe acl_add(acl, "user", "123", "read,write")
<alex> or a glist
<gicmo> maybe a glist is easier to "parse"
<alex> yeah
<alex> its harder to write the code to just set one thing (like the above line)
<alex> but thats an uncommon thing to do i guess
<gicmo> and in the GnomeVFSAcl Object have a table with all the "user:id" -> value .. hmm or something .. [user, user1, user2 ..] -> key -> value .. not sure .. 
<alex> you either copy an old acl or break up the whole ACL into "UI" and the reencode the whole UI back into an ACL
<gicmo> acl_add(acl, "user", "123", g_list_prepend (NULL, (gpointer) "read"));
<gicmo> is still ok .. a bit more . uhmm .. well :)
<alex> it leaks
<gicmo> ohh wait maybe you have to free the list later :)
<gicmo> yeah ..
<alex> but its not likely something that any code will do
<gicmo> yeah ...
<gicmo> I should come up with a gnomevfs-acl cmd line tool as well ;)
<gicmo> It's Going To Be Work[tm]
<alex> its unlikely that any code will set any ACL but the default one or a copy from another file, except nautilus ACL dialog and maybe a command line tool
<gicmo> yeah .. agreed
<alex> so, the API should be designed for that usecase
<gicmo> <nod>
<alex> i.e. I have an ACL, i wanna fill out the ACL dialog
<alex> I have an ACL dialog, i wanna create (or update?) an ACL from it
<alex> or s/ACL dialog/cmdline args/
<gicmo> I guess if you have an ACL object and you wanna set stuff on a uri and the method doesnt support all of it we should try to set as much as possible ..
<alex> yeah
<alex> but it should somehow be possible to know what the backend supports
<alex> so that you can modify the ui
<gicmo> designing the GnomeVFSAcl container object well be a bit tricky :)
<gicmo> yeah .. but in that case you can just ask the backend itself .. which is independet from the container object, right?
<alex> List of (possitive/negative, kind, id, list-of-tags)
<alex> might be enough
<gicmo> yeah ..
<alex> sure, the detection is a backend-thing
<gicmo> ok ok .. that brainstomring seems a good starting point to me .. 
<alex> yeah, i don't think we can actually get much further without trying to implement it
<alex> did you save the log?
<gicmo> not yet .. 
<gicmo> did you?
<gicmo> maybe attach it to bugzilla would be a good thing?
