Hi there, i am working on the following "future idea"
*Client should first send the checksum and size of large objects when they store something (import, adding or updating data), in many cases the actual data does not need to be sent.* found in http://wiki.apache.org/jackrabbit/DataStore#Future_Ideas So far i checked both extremes (repo client and repo service) and i think i reached the responsible classes for the sending / receiving the file to be (potentially) stored: (1-client ------------------------------------------------- network ------------------------------------- 2-JR webapplication) (1-org.apache.jackrabbit.jcr2spi.WorkspaceManager:594) (2-AbstractWebdavServlet) * For JR 2.2.7 source code. So, the point i am now at is trying to understand all the prior checkings that are done on both sides in order to include this improvement in the correct place within code (please tell me if i'm wrong so far). Anyway i would like to ask to any JR master that reads these lines about some issues: - i noticed that JR correctly exposes the files uploaded twice (one file, multiple URLs). Can i assume that such links will be deleted when running the garbage collection? (i.e.: a single file exposed through multiple links, deleting links doesn't delete the file - except for the last link -, isn't it?) - the FileDataStore class directly accesses the underlying SHA1-based folder structure on disk but, which would be the best way to ask about such structure to the server side from the client side? - my guessing now is that the best way to introduce this new behaviour would be in the prior checkings to the javax.jcr.Session save() method (ask the server side and if present behave just like now but saving the network transfer). - what would be more efficient? Checking in the inUse map (large but in main memory) about the existence of the received-from-the-client hash or checking for the existence of a the file (simple but accessing the hard disk)?. - ... am i missing something relevant? Thank you very much in advance for your attention!!!
