On Tuesday 11 March 2008 12:38, juergen urner wrote: > Matthew Toseland schrieb: > > On Monday 10 March 2008 23:48, juergen urner wrote: > > > >> Matthew Toseland schrieb: > >> > >> Yes, I noticed that. And I noticed that 'Filename' is not present in > >> PeristentPutDir > >> when I pass ClientPutComplexDir. just a bit of ugly parsing to find out > >> 'Filename' > >> I'd like to avoid. So, at least passing 'Filename' as indicator would be > >> helpful. > > > > It's present for each file, but there is no overall Filename because a > > ClientPutComplexDir can put files from anywhere. > > 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? > > Yes | No | Cancel > > >> 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? I'm curious what you are trying to do that needs to parse a PersistentPutDir ? > 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? > 4. readable docs? What's wrong with the current documentation? > > > 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. > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080311/2e18617b/attachment.pgp>
