Daniel Vr=E1til writes: > On Sunday 04 of May 2014 23:43:15 Bhaskar Kandiyal wrote: > > couple comments from me: > * How do you differentiate between item and collection? If I do "akonadic= lient = > delete 15", is that a Collection, or an Item? Collections and Item IDs ca= n = > overlap. Same for "move" i suppose. I've thought about this ambiguity before, but have not got around to implementing a solution. Currently the 'info' command implements options '-i' and '-c' to explicitly specify whether a plain number is to be interpreted as an item or collection ID, but it's a clumsy way and it means that every command that can take either an item or collection has to implement these options. A better solution, by analogy with C++ number syntax, would be to add a suffix - for example, "1334i" (case insensitive of course) would mean an item while "1334c" would mean a collection. A number without a suffix would mean whatever was appropriate if only an item or collection would be valid (e.g. the argument for 'list' is always a collection), otherwise it could be rejected as ambiguous. Named collections have to start at the root*, so there can be no ambiguity between either of those and a collection named "1334c" (which would have to be entered as "/1334c". [*] Unless we implement a "command loop" when invoked without arguments, such as in xauth, lpc or the Perl CPAN shell. With this persistence there can be the concept of a "current collection" and a cd command to move around. Then a plain number could potentially have three interpretations, and there would have to be a notation to distinguish between 'a subcollection of the current collection named "1334"' and 'the collection with ID 1334'. > * What is the purpose/use case for this tool? (Sorry, I don't know your G= SOC = > proposal) Unless it's supposed to be a developer tool, having an option t= o = > query the SQL backend is a bad move IMO. The fact that Akonadi is using a = > database is an implementation detail that should not be exposed to users = in = > any way. Executing SQL queries on the database (unless you really know w= hat = > you are doing) can be dangerous, and we have Akonadi Console for doing = > dangerous crazy things with Akonadi ;-) I'd agree with this. If a developer really wants to script and execute raw SQL on the database, then they may as well use mysql directly. The only point in having an "SQL forwarder" in akonadiclient would be to abstract away details of the database backend and configuration, but any SQL would likely be database-specific anyway. > * I'm not sure what's the difference between "add" and "import" ? Both ta= ke a = > file and add it to a Collection (parent). The only difference I can see i= s = > that "add" can work with multiple files, but then "import" is just crippl= ed = > "add" and is not needed? > > * A general question: what is format of the files that "add" or "import" = > expects? Is it a defined XML format, or just the raw payload? In that cas= e you = > probably want to be able to specify additional attributes, or multiple pa= yload = > parts? For 'add' it is currently the raw payload (auto detected MIME type). The import/export commands that Bhaskar has already prototyped use XML. > And so that you don't say I just criticize, some more ideas you could add= :-) > > * list only collections - sometimes it might be useful to get only the tr= ee = > hierarchy of collections, without the items > > * list only items in a collection - sometimes you don't care about = > subcollections ;-) This is already possible with the '-c' and '-l' options to the 'list' command - which is a different interpretation of the same options for the 'info' command, another good reason for not using them for item/collection disambiguation as above :-) Regards, Jonathan -- = Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK jjm2@keelhaul.demon.co.uk _______________________________________________ KDE PIM mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/