I have added a bug. It is unlikely that it will happen before 0.7.0. https://bugs.freenetproject.org/view.php?id=2159
On Tuesday 11 March 2008 15:52, juergen urner wrote: > 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. > > > > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -------------- 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/420fc569/attachment.pgp>
