Hi Greg, > Since these tasks will be reading from/writing to the file system, IOTask is > probably slightly better. However, the only thing IOTask really offers beyond > Task is stream monitoring, which you're not likely to need to use here. So > either one is fine. OK.
> You shouldn't need to synchronize anything here - that is handled for you by > the Task class. Ok, great, but first one important question (to better understand the design of Task-based operations in Pivot): in my implementation the url and Service get/usage was from inside Preferences, while with the Task-based approach, would it be better to move these to any task ? And then, remove methods like load/save/etc (or make them private, if we don't want others to use directly them) ? Otherwise i could keep the current code under tasks (if working right, i haven't tested the task approach with my code at the moment), so any tasks call preferences methods like load, save, etc ... and leaving the load, save, etc methods public so anyone can call them also in synchronous way, like now. What do you think it's the best approach ? >>- as by Web Start Persistence constraint, it's not possible to >>save/load data using a real URL (unless it's derived from the Codebase >>URL form where the application has been downloaded), so what do you >>think that instead of have a parameter URL url in constructors, if we >>use there a String name ? This could help to remove and simplify some >>code (like fixUrl, static utility methods, and other tricks) ... > > I have to believe that this is a common problem when writing Web Start apps. > See if you can find some documentation on how other developers have handled > this. OK, but there isn't a lot of infos/articles, sigh ... Here there is a sample related to a Web Start Persistence engine for (Apache) Derby DB, take a look: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200706.mbox/%3c30033028.1181637326406.javamail.j...@brutus%3e , or the longer thread: https://issues.apache.org/jira/browse/DERBY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel It seem that they use URLs, so i can align with this and not remove some utility methods, ok. But they use a recursive structure simulating nested directories with empty files created with persistence, and finally using a flat namespace (as from Web Start Persistence) limitations. In our case I wouldn't implement a complex approach like that (they have to simulate a file system, for all DB operations), until not required. >>- verify if implement other XxxxTask methods for remaining "user" >>public methods (dump, exist, delete, list), and then, if remove old >>versions of them (standard methods inside Preferences), or at least if >>keep only dump() ... > > I don't think we need these methods, since you can get the same functionality > from JSONSerializer. mhhh, here i think that methods like delete are needed also by users (for example for cleaning up old files), and the others like check (the existence of a preferences file) and list (existing preferences files) could be very useful too. >>- listeners, must they be added to standard methods (get/put/remove), >>or are they already ok as in Greg stub ? > Ok. > I've tried to make it as simple as possible. :-) Just plug your > serialization code in where you see TODO in the comments. You shouldn't need > to do much beyond that, but let me know if you have any other questions. Yes, as always thanks for your help !! Bye, Sandro
