On Thursday 20 March 2008 10:05, juergen urner wrote:
> Matthew Toseland schrieb:
> > [SimpleFiledSet and Fcp]
> >> This is a nasty one: dotted names. It may be easy or not for some
> >> languages to deal with
> >> this data type. Actually it is easy in python, but doing additional
> >> processing based on
> >> message signature (like type conversions) is pretty painful and costy.
> >> Flat messages
> >> shopuld be way easier to handle. Already made a suggestion regarding
this...
> >>
> >
> > I really don't understand what the difference is. We provide a Count. If
you
> > are parsing into a tree structure, it's trivial. Even if you're not,
you've
> > got the Count, so you can allocate the array before you parse the
sub-items.
> > Given a multiplexable protocol, using separate messages would mean having
an
> > identifier in each one which would be just as messy. The only reason to do
it
> > the way you propose would be to avoid very large messages.
> >
>
> From the top of my head, happily breaking everything in the current
> protocol
>
> Request
> ID=any
> Key=any
> NItems=N
> ReturnCode=N
> UserData=any
> (...)
> End
>
> Item
> ID=any
> (...)
> DataLength=N
> ReturnCode=N
> UserData=any
> End
>
>
> request = Request(ID='MyRequest')
> item = Item(ID='MyRequest/Item1')
>
> ---------------------------------------------------------------------------
> send request followed by N items, the node will send back request and
> item with an error code set
Why do you want separate error codes for each file? They're all being uploaded
into a single manifest, often they may even be all being uploaded into a
single container, even if they're not their top level metadata will usually
be in container; they're not easily separable.
>
> [ID]
> hirarchical name used to identify requests and sub-requests. Should
> start at connection name
> so it is guaranteed each request can be identified uniquely. If apps
> feel the need to share
> requests, they simply have to share their connection name (though not
> recommended, collisions
> can not can not be excluded here). Global queue would then be: enumerate
> all known
> connections / requests with FlagPrivate not set.
IMHO hierarchy beyond requests isn't very useful at this point.
>
> [UserData]
> (ClientToken as I understood it). Gives clients a uniform way to
> associate any data desired to a request.
>
> Pros:
> x. no identifier collisions
Not true. There's no reason to get identifier collisions if you generate
unique identifiers. If you don't, well, you can get collisions and you need
to deal with them. Also, on the global queue, you can get collisions.
> x. 'flat' mesages (easy to handle)
We are not going to make radical changes to FCP at this point. Backward
compatibility may suck, but it's necessary when we have a number of working
and widely used clients. Minor changes are however of interest - if they are
justified.
> x. nestable / multiplexable if desired
> x. easy to extend
> ...GetRequestStatus('ConnectionName/MyRequest/MyRequestItem')
> x. save for clients. GetRequest('ConnectionName/Request'). Ups ...1M
> items, we don't do that.
A better solution to that problem is to not return the list of sub-items with
a PersistentPutDir.
>
> Cons:
> x. still no guarantee that ConnectionName may not collide with another
> apps ConnectionName. This will be a risk as long as the node administers
> client data.
It will be a risk as long as the connection name is generated by the client
rather than the node.
> x. ???
>
> J
-------------- 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/20080320/2f32bad7/attachment.pgp>
