Archived

This forum has been archived. Please start a new discussion on GitHub.

IcePatch design question

Hi there!

Could you please give me a design advice for a program that is quite similar to IcePatch:

Apart from only being able to download data, the program should also support uploading data.
This would be implemented by adding an upload() function to CFile.

Thus, a factory would be used to obtain a handle for new CFile and CFileDesc objects (file object server-side, fileDesc is then client-side) and then the upload() function of CFile would be called.
Having uploaded a file, the md5 descriptor in CFileDesc would surely become invalid.
Unfortunately, there's no connection between the file and fileDesc objects to make sure that fileDesc is being invalidated.
Imho, the only possibility for a slick solution is to wrap the functionality on the client-side thus that another client-side component is responsible for the upload. This client-side component would also have to know about the fileDesc to invalidate it, thus one would need a function like this:

bool uploadFile(CFileDesc& desc, ByteArray data)
{
try
{
desc.fileHandle->upload(data);
}
catch ()
{
return false;
}
desc.bValid = false;
return true;
}

Is this the only possibility or are there ways to avoid such wrapping (i.e. working only with file and fileDesc)?

regs,

Stephan

Comments

  • mes
    mes California
    Hi Stephan,

    If I were going to add an upload operation to IcePatch, I would probably add it to the Directory interface. This would allow me to manage the file objects in a transactional way, i.e., the uploaded data is stored in a temporary file, and the file is only replaced once all the data has been uploaded successfully. I would also hold a lock while replacing the file to ensure that a client doesn't get inconsistent information.

    There isn't anything you can do about an invalid FileDesc instance that a client already possesses; you just have to wait for the client to notice that the MD5 no longer matches.

    Hope that helps.

    - Mark