Matthew Toseland schrieb:
> 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.
>
Just to get emidiate feedback in case something goes wrong. May not be
needed
to do it that fine grainded, but it leaves the door open.
>> [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.
>
...leaves the oor open.
>> [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.
>
Had this one before and I like the discussion :-) Uuids are very* likely
to be unique.
That is, be prepaired for next collision, monday. That's what the
current protocol
is handling well. But there is no reason to use unique identifiers in
the first place
if identifiers point to separate namespaces.
>
>> 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.
>
Just playing with ideas. Shurely not Fcp2. Fcp3 maybe. But if I am not
too wrong
it should be worth the trouble for all clients.
>> 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.
>
I'd consider it dangerous passing all at once. Some apps may get into
troubles
by blindly accepting requests that other apps can deal with easily.
Currently
it works. But a C client can shurely deal with way more requests (subitemms
whatever) than a Java client can do. Unless the node is not the bottleneck
that is.
>> 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.
>
Yes, in this case the node would have to generate a unique name /
connection. If the
node can guarantee uniqueness (easy), everything is guaranteed to be
unique from
then on. But sadly no way to tackle collisions without breaking the
current protocol.
