Pithos MS Client: Issueshttps://code.grnet.gr/2011-09-18T15:49:52+03:00Greek Research and Technology Network's projects
Redmine Feature #1205 (Closed): Add code to retrieve the Tokenhttps://code.grnet.gr/issues/12052011-09-18T15:49:52+03:00Panagiotis Kanavos
To retrieve the token, register a custom schem with the PITHOS client (e.g. pithos://) and
<ol>
<li>Open a browser window with the url <a class="external" href="http://pithos.dev.gr/login?next=pithos://someurl">http://pithos.dev.gr/login?next=pithos://someurl</a></li>
<li>The browser is redirected to Shiboleth and redirects to the pithos:// url with the token in a header</li>
<li>The client app is activated to handle the request and retrieves the token from the header</li>
</ol> Feature #1199 (Closed): Upload/download hashmaps for each filehttps://code.grnet.gr/issues/11992011-09-18T15:17:32+03:00Panagiotis KanavosFeature #1197 (Closed): Modify uploads of existing files to use hashmapshttps://code.grnet.gr/issues/11972011-09-18T15:17:03+03:00Panagiotis KanavosFeature #1195 (Closed): Add hashmap storage for local fileshttps://code.grnet.gr/issues/11952011-09-18T15:14:19+03:00Panagiotis Kanavos
<p>Add mockable hashmap storage</p> Feature #1193 (Closed): Create hashmap calculator for local fileshttps://code.grnet.gr/issues/11932011-09-18T15:13:25+03:00Panagiotis KanavosFeature #1189 (Closed): Display tags in a property windowhttps://code.grnet.gr/issues/11892011-09-18T15:04:09+03:00Panagiotis Kanavos
<p>Since arbitrary tags can't be stored and displayed using the file system's properties, we need to store tags locally and display them in a property window. This window will be displayed by the Pithos client.</p> Feature #939 (Closed): Store last succesfull download sync datehttps://code.grnet.gr/issues/9392011-07-25T12:56:57+03:00Panagiotis Kanavos
<p>The last download sync date should be store upon completion to persistent storage. It will be used later to retrieve only changes that occured since this date.</p> Feature #937 (Closed): Make change operations that result in uploads restartable.https://code.grnet.gr/issues/9372011-07-25T12:55:35+03:00Panagiotis Kanavos
<p>Change operations that may result in uploads should be logged to persistent storage so the operations can restart if the client or the computer fails for any reason.</p>
<p>Alternatively, the client may download a list of all objects (or all objects changed since the last succesful download sync) and check those files that were modified since.</p> Feature #935 (Closed): Multiple related change modifications should map to a single, retriable, u...https://code.grnet.gr/issues/9352011-07-25T12:51:32+03:00Panagiotis Kanavos
<p>Operations on even medium sized files result in multiple change notifications. It is not possible to detect when an operation finishes. Therefore, it should be possible to create one upload operation that corresponds to a single upload operation. When the operation is ready to execute, the client should check whether the file is already opened. If the file is closed, proceed with the upload.</p>
<p>If the file is open, either:</p>
<ul>
<li>Requeue the operation for later execution, perhaps with a small delay</li>
<li>Or try to upload a previous version (e.g. using the shadow volume API). Even in this case, the operation should be retried at a later time to upload changes that happen after the file closes.</li>
</ul> Feature #933 (Closed): Prevent change notifications for downloaded fileshttps://code.grnet.gr/issues/9332011-07-25T12:44:39+03:00Panagiotis Kanavos
<p>Downloading a file will create change notifications that will have to be ignored and not result in an upload operation.</p> Feature #925 (Closed): Display a PUBLIC folder that corresponds to the PUBLIC containerhttps://code.grnet.gr/issues/9252011-07-25T12:18:38+03:00Panagiotis Kanavos
<p>The client will create a PUBLIC folder that will be synched wit the PUBLIC container</p> Feature #923 (Closed): The client will sync shared containers found in the OTHERS containerhttps://code.grnet.gr/issues/9232011-07-25T12:11:15+03:00Panagiotis Kanavos
<p>The client will read the OTHERS container to find folders shared by others and sync their contents to the local disk.</p>
<ul>
<li>Shared folders will appear with a different icon <b>4h</b> because it goes beyond the Tortoise icons, needs own icon</li>
<li>For each sharing account, display a folder below the "OTHERS" local folder. If the account contains only a single container (pithos), display the shared object below it directly. Otherwise display the containers, folders etc. <b>6h</b> (remember the single container when synching)</li>
<li>The user will be able to select which shared folders to sync, in the same manner as other folders</li>
<li>Share permissions should be reflected by file system attributes and/or permissions, to prevent modifications that will be rejected by the server. Object level permissions can be enforced by the "read only" attribute. Folder-level permissions will probably need permissions. <b>6h</b></li>
</ul>