Matthew Toseland schrieb: >> ClientPutDiskDir can not. Thinking it over it is impossible >> to tell if a PeristentPutDir results from a complex or a diskdir. >> > > There is no easy and reliable way to tell yes. > >> I have to tell my user, sorry, I don't know what your initial >> request was. I throw the put directory mask at you, right? >> > > Why do you need to tell your user? I assume you need to be compatible with > PutDiskDir's sent by other apps than your own? >
No, no other apps. User requests upload of a directory, later he wants to send the request again. That is the directory, not the files listed. No problem attatching the directory as part of a struct in ClientToken, but I rather raise for 'Filename' being passed. >>>> Put* is somewhat overcomplicated. I am already scared of future >>>> extensions to it. >>>> >>> The example given on the wiki has only the minimum info needed for each >>> > file: > >>> ----- >>> ClientPutComplexDir >>> Identifier=My Identifier >>> Verbosity=1023 >>> MaxRetries=999 >>> PriorityClass=2 >>> URI=SSK at Fk6sQ6...../myinsert-4/ >>> GetCHKOnly=false >>> DontCompress=true >>> ClientToken=My Client Token >>> Persistence=reboot >>> Global=true >>> DefaultName=hello.txt >>> Files.0.Name=hello.txt >>> Files.0.UploadFrom=direct >>> Files.0.Metadata.ContentType=text/plain >>> Files.0.DataLength=59 >>> Files.1.Name=something.pdf >>> Files.1.UploadFrom=disk >>> Files.1.Filename=something.pdf >>> Files.2.Name=gpl.txt >>> Files.2.UploadFrom=redirect >>> Files.2.TargetURI=KSK at sample.txt >>> EndMessage >>> hello, this is the contents >>> of the file called "hello.txt" >>> ----- >>> >>> AFAICS the only difficult thing about the above is that you have to prefix >>> each file with <Files.n.>, rather than sending them as separate >>> > messages... > >>> what's the big deal? >>> >> 1. what is nice and clean about it? >> 2. parsing - instead of running a loop for items in container one has to >> gather >> items by hand. if ..else ..elif, checkIndexIntergrity() >> > > Okay, I see. Because you don't turn the message into a tree first (using > SimpleFieldSet), as the node does, but parse it directly, the current format > is harder to deal with than the proposed format. This may be an argument to > change PersistentPutDir. > > Would it help much to add a Count before the Files list? > No, not much. > I'm curious what you are trying to do that needs to parse a PersistentPutDir ? > The need originated from building test cases for my Fcp client. Later I stumbled over the case where a user uploads a ComplexDir. On next connect I have to parse PeristentPutDir in order to present a graphical mask containg details to the user. >> 3. there may be many* items. In future extensions it may be possible to pass >> items one by one and query them on demand. >> > > I don't see how that would help, surely it would only complicate matters? > Maybe you are right. But what I would like to see is an api for querying ConfigData and persistents on demand. So, for uniformity reasons some (uh, how do you say) standard for container processing would be nice. >> 4. readable docs? >> > > What's wrong with the current documentation? > Nothing. But (hope this does not sound impolite) I always assume that if the documentation is hard to follow, my api is in need of a redesign. >> Put: >> ------------------ >> Requests the node to upload one or more items >> >> Put >> params here >> Plum >> >> Items have to follow the Put message emidiately. >> > > No they don't. FCPv2 is designed to be multiplexable. Therefore the items > will > have to have an identifier referring back to the PutDir. > For sanity reasons, I hope Identifier=ParentRequestIdentifier is enough. >> Items can be one or more of the following: >> >> DataItem >> --------------------- >> Uploads raw data >> >> DataItem >> params here >> Plum >> >> Attatched data has to follow emidiately the newline after the item >> terminator >> > > Of course. And a data-item-with-data, as opposed to a > data-item-referring-to-a-file-on-disk, will need to have a DataLength. > Yes. And DataLength is reserved as message metadata field. Or something like 'NBytes' if you like it more formal and backwards compatible.
