[Tech] Fcp woes II

[Matthew Toseland]

On Monday 10 March 2008 23:48, juergen urner wrote:
> Matthew Toseland schrieb:
> > On Sunday 09 March 2008 15:25, juergen urner wrote:
> >   
> >> There is no distinction between ClientPutDiskDir and ClientPutComplexDir
> >> in PersistentPut*. This makes it hard to tell both apart. I need this to 
> >> do automatic
> >> type conversions.
> >>     
> >
> > We can make a distinction if we need to, however there really isn't much 
> > difference, ClientPutDiskDir is just a simple way to access the same 
> > functionality, any ClientPutDiskDir can be expressed as a 
ClientPutComplexDir 
> > if need be.
> 
> 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.
> 
> >> Just thinking aloud ..I wish ClientPut* (PersistentPut*) would go. 
> >> Afaics a new message
> >> would make live much easier on both sides. Any thoughts?
> >>
> >> Put
> >>     Identifer=any
> >>     NItems=N
> >>     Persistence=whatever
> >>     (...)
> >> EndMessage
> >>
> >> ...emidiately followed by N items to put
> >>
> >> DataItem
> >>     DataLength=N
> >>     Name=any
> >>     (...)
> >> EndMessage
> >> FileItem
> >>     Filename=filename
> >>     Name=any
> >>      (...)
> >> EndMessage
> >> (...)
> >>     
> >
> > Why is this better?
> 
> 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"
-----
> 
> As I see it, all that is needed is is to break the container into its 
> peaces to
> make a nice and clean api for both sides on only one message and one page
> in the wiki.

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?
> 
> >> Btw, on input Fcp does not seem to care if Files.N.* in 
ClientPutComplexDir
> >> start at 0. This broke persistents.
> >
> > You mean it expects it to start at 0? Or what?
> 
> Yes something breaks. Too lazy to run more tests, but NodeHello does
> not arrive anymore.

Look for a NullPointerException in the logs.
> 
> Btw, I ran a test throwing 'Plum' as message terminator at the node.
> 
>  >>> If '=' not in chunk:
>  >>>    endOfMessageEncountered()
> 
> Fcp doesn' t care at all?

Indeed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080311/e0da1e2d/attachment.pgp