On Mon, Nov 10, 2014 at 2:18 PM, Thomas Mortagne <[email protected]> wrote:
> On Mon, Nov 10, 2014 at 12:46 PM, Eduard Moraru <[email protected]> > wrote: > > On Mon, Nov 10, 2014 at 1:06 PM, Thomas Mortagne < > [email protected]> > > wrote: > > > >> Pretty much the same comments here. > >> > >> On personal side this is one of the thing I hate about Windows ("just > >> do what the hell I told you to do and don't try to be clever"). > >> > > > > I agree with that, but on the practical aspects, how often do you need to > > have in the same folder all the following files: > > - "test > > - "TEST" > > - "Test" > > ? > > > > Also, as Marius pointed out, the FAT/Windows filesystem is case > sensitive, > > it just has an uniqueness constraint, so you can name stuff however you > > want to, just don`t have duplicates because you will quickly make a mess > of > > yourself. > > > > It's easy to use the above argument for various cases, however IMO our > goal > > should be to write useful software, and the features we are discussing > here > > are mainly targeting the users, not the admins. My logic tells me that > > users are more interested in resources and not in resource names. > ("potato, > > patato" [1] - see the OP on same resource, multiple names because of > > casing). > > It's not so much about common use case that the fact that having two > files with different cases do exist (because pretty much everything > that is not system dependent is case sensitive) but in Windows I won't > be able to just download them without having to think about it and if > they are in a zip, just unzip it won't work, if there is such files in > a git repository I won't be able to clone or update it on Windows, > etc. Also because Windows is so clever you simply can't change your > file's case, you have to rename your file to something that does not > match and then rename it to what you really want. On the other hand > having two files with different cases in a folder never was an issue > in any way for me on Linux. > > In other words being sure that I can copy/download/import anything > anywhere without having to worry about path size, support characters, > getting conflict that never really existed, etc... is of more interest > to me than being totally lost (it's so complex to understand, right) > because I have two files with different case in a folder. > > I don't really see how stating that I'm not annoyed by the right > things and saying that Windows is actually great with the use case I'm > not having is going to help the debate. I already said that I have a > technical point of view and having matching between two files of > different case can be of some interest for basic users. > > In the use case of XWiki what I don't like is similar to what I > explained for Windows which is that I don't like too much changing the > whole platform to make impossible to support something that might be a > real use case for any reason, impossible to import a XAR with two > pages having different case, impossible to attach files with different > case because you need it to be that way because you are using a tool > that needs it that way, etc... Basically I don't like adding a > limitation that is far from being a universal limitation. > Well, yes. In Windows you will always have frustrations when making it work with other systems that don`t have uniqueness constraints, so it`s obvious you will have problems. In XWiki`s case, at some point you should not have a XAR with 2 documents with different casing in the same space, except if dealing with older versions. (migrations from other wiki systems is another case when you might hit this). For attachments I was not proposing an uniqueness constraint since the collision chance is higher (files coming from different folders on the user's HDD end up in the same space, so c:\test.txt and d:\Test.txt both end up in Main.SomeDocument => collision). Also, it's easy to spot a collision on an attachment since you see the list of attachments you have uploaded. When creating a document, your focus is narrowed and you don`t really see documents "around you". Anyway, your points are valid and I agree that we should probably just avoid all the confusion caused by this costly transition. I guess the UI suggestion improvements is the only thing we are left with at the moment. Sure, we could try adding uniqueness constraints just at an UI level, which could also be configurable, while the platform would remain free to do whatever it wishes, just as long as the UI is always aware that duplicates, even if not allowed to, could still exist. Of course, being an UI thing, it would not be guaranteed, even if enabled, since each application could do whatever it wishes in its UI or its components; so more of a "hit or miss" if anyone tries to enable it. Thanks, Eduard > > > > Thanks, > > Eduard > > > > ---------- > > [1] https://www.youtube.com/watch?v=Mc3Fn7R9mkE > > > >> > >> On technical side everyone should understand that this is a huge > >> refactoring that will produce regressions for at least one year. > >> Another things is that it's slower so performance are going to be > >> worst in most of the XWiki code. > >> > >> On Mon, Nov 10, 2014 at 11:24 AM, Marius Dumitru Florea > >> <[email protected]> wrote: > >> > I'm undecided. As a technical Linux user I prefer case sensitivity, > but I > >> > can see why this is sometimes unexpected for non-technical users. I'm > not > >> > sure how you plan to implement this. I know this thread is not about > the > >> > technical aspects but still I think it's important to consider the > cost > >> > that this change will imply. > >> > > >> > First, even for a case insensitive system, I think it's very > important to > >> > preserve the case entered by the user. For instance, If I create a > user > >> > with the alias 'myCoolAlias' then I wouldn't like to see 'mycoolalias' > >> > displayed in the UI. Same, if I attach a file named > >> > 'myCoolPresentation.odp' then I want to see precisely that name on the > >> list > >> > of attachments. So we need to store case sensitive values in the > >> database. > >> > The difference from now will be: > >> > > >> > * when creating an entity: check that there's no other entity that has > >> the > >> > same normalized reference (toLowerCase/toUpperCase) > >> > > >> > * when retrieving an entity: look for normalized references > >> > > >> > This means we'll have to call toLowerCase/toUpperCase very often so we > >> need > >> > proper database indexes. Otherwise we'll have a performance impact. > >> > > >> > Second, we have lots of places that query the database and since we > have > >> to > >> > store the raw case-sensitive values then we need to update all this > >> places. > >> > Moreover, since it's not about a single field/column I'm not sure we > can > >> > write a query filter to lower the case automatically. Then we also > have a > >> > lot of extensions that query the database and that create entities. > Those > >> > will have to be updated too. > >> > > >> > Lastly, AFAIK lower case and upper case are locale dependent. The > 'lower' > >> > query function doesn't have a locale parameter so it depends on the > >> locale > >> > the database has been configured with. So there can be cases when a > user > >> > won't be able to retrieve an entity using some locale dependent > lowercase > >> > version of the reference because the database computes the lower case > >> > differently than what the user expects (because it uses a different > >> locale). > >> > > >> > > >> > Thanks, > >> > > >> > Marius > >> > > >> > > >> > On Nov 7, 2014 12:34 PM, "Eduard Moraru" <[email protected]> > wrote: > >> >> > >> >> Hi users and devs, > >> >> > >> >> I would like to have your opinion on the topic of case sensitive vs > case > >> >> insensitive and which one you prefer in XWiki. > >> >> > >> >> Currently, XWiki is case sensitive. This means the same resource name > >> >> (document name, space name, etc) can be written with either small > >> letters > >> >> or big letters or a mix. > >> >> > >> >> Examples: You can have both "Main.Test" and "Main.test" as 2 > different > >> >> documents. Also, you can have "XWiki.Admin" and "XWiki.admin" as 2 > >> >> different users. This also applies to URLs, as "/Main/Test" is > different > >> >> from "/Main/test" or "/main/test", so all these 3 are different > >> resources. > >> >> > >> >> Even from this short description, one can already identify possible > >> >> problems of this approach. > >> >> > >> >> From the top 3 operating systems (Linux, Mac an Windows), only Linux > is > >> >> case sensitive, the other two (more user-focused Operating Systems) > are > >> >> both case insensitive. > >> >> > >> >> Since XWiki has one of its main targets the Enterprise users, it is > safe > >> > to > >> >> assume that the correct approach would be to also be more > user-focused > >> and > >> >> simplify things and avoid confusions by being case insensitive as > well. > >> >> > >> >> Also, a quick search on existing issues validates the need for this > >> >> improvement: > >> >> > http://jira.xwiki.org/issues/?jql=text%20~%20%22case%20insensitive%22 > >> >> > >> >> What do you think? Is it OK to keep XWiki case sensitive, or would > you > >> >> prefer it case insensitive? Bring arguments. > >> >> > >> >> I have also created a jira issue for this idea: > >> >> http://jira.xwiki.org/browse/XWIKI-11412 to track it in the future. > >> >> > >> >> Thanks, > >> >> Eduard > >> >> _______________________________________________ > >> >> devs mailing list > >> >> [email protected] > >> >> http://lists.xwiki.org/mailman/listinfo/devs > >> > _______________________________________________ > >> > devs mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > >> > >> > >> -- > >> Thomas Mortagne > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
