On Thursday 20 March 2008 15:56, juergen urner wrote:
> 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.
Well, if a single block insert fails, you get notified in the SimpleProgress.
If a file isn't accessible you'll normally get a protocol error at submission
time, i dunno what happens later on.
>
> >> [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.
Identifiers exist within separate namespaces. Each client Name defines a
namespace, and there is also the global queue's namespace.
>
> >> 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.
If you want to implement a completely new client-to-node protocol, you are
welcome to send a patch in.
>
> >> 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.
It is easy enough to ignore messages you can't parse. And you won't encounter
any unexpected requests anyway unless you are watching the global queue.
What do you think of not sending the sub-items on the PersistentPutDir unless
some verbosity flag is set?
> 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.
Worse, the client would have to store it for persistent requests. Which also
sucks. It would be better imho for the client to generate a hopefully unique
name, and then the node can reject it if necessary.
-------------- 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/d159bc38/attachment.pgp>
