Just dropping by to tell, that I finally resign on writing a highlevel
Python wrapper
for the protocol. There is still too many show stoppers in there to
write it nice and
clean.
I'd like to give some feedback on what made my live hard. Maybe s.o. can
make
use of it. In no particular order....
-------------------------------------------------------------------------------------------------------------
[Global queue and persistence]
Already reported. Maybe one last note regarding this. If apps feel the
need to share data
it should be up to them to organize this.
[Persistent requests vs. non persistents]
x. one may want to modify or remove non persistent requests aswell
this should eliminate all the case switches if
Persistence==connection else...
x. there should be an explicite way to stop, resume all kinds of requests
[DataFound vs. AllData]
Another case switch that looks rather unnecessary. AllData is not send
for persistent
requests. Looks loke a very special case to me, maybe some Frost. Imo,
if there
is a need to split data fetching and whatever-client-wants-to-do-with-data
apart, doing it explicitely could be much clearer. Something like...
client --> node
GetData
End
node-->client
DataFound
End
client-->node
GetDataAs
Filename=
Direct=
End
[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...
ContainerMessage
NItems=N
End
Item
End
[Message signatures and consts]
(already mentioned before) a good to have would be a file containg all
consts and message
signatures used in Fcp. It should go into very detail regarding types
aswell. TypeIPAddress. TypeIPAddressList (...)
This would save much typing work and could help in autogenarating huge
parts of protocol wrappers.
[Organize requests hirarchically]
This may sound exotic, but it could help in organizing requests.
Especially when it comes to restoring
requests, where it may be desireable to process requests on demand.
Something like
GetRootRequest ..ListChildRequests
[Reserve DataLenght as indicator of data attatched to a message]
(Already mentioned) makes message parsing much easier if one can rely on
this field being
reserved as message metadata.
[ConfigData, NodeData, Peer should be traversable]
See [Organize requests hirarchically]
[Drop Started field in Persistent* messages]
Maybe use simple progress instead, and / or some dedicated field to
indicate request status.
This could be helpful anyways if requests may be stopped, resumed (...)
at some point
[Dedicated Result field in messages]
In case something goes wrong, it would be nice to have the message
casing the error
at hand right away. ++ ProtocolError, FetchError, InsertError are not
very handy. They
should be numbered consecutively. I found myself writing a wrapper to
emulate this
(uniformity).
[ClientToken field for all messages]
It may be desireable to keep track of all messages and responses. Like
for example GetConfig
and Config to tell when all tasks a user has posted are completed.
ClientToken would come in
handy.
...maybe other things I can't remember now.
--------------------------------------------------------------------------------
Finally, in case someone is interested the wrapper as complete or
incomplete as it is:
[http://fclient.svn.sourceforge.net/viewvc/fclient/trunk/sandbox/fcp2/]
Thanks, Juergen
