On May 19, 10:28 am, Laszlo Nagy <[EMAIL PROTECTED]> wrote: > > I don't think that it is important. But if you are interested: > > - yes, the server will probably be I/O bound, not CPU bound > - I'm have experience with thread programming, but not with twisted
That part was just to show you that being multithreaded is not really a requirement. The server could be single-threaded, for example. Surely, if you are comfortable with writing a threaded server, there's no problem with that. > > No. "Image binary data -> base64encode -> XML -> gzip" - looks very > silly. It cannot be efficient. Do you have better ideas?>> BTW I do not care > about the Okay, that would be silly. The questions above considered that you would be sending typical unserialized objects that would be serialized to XML, not pre-serialized binary data. > use it. The server is different: it must be safe against external > attacks. Maybe it was my bad English? Sorry for the misunderstanding.> In > general I That part was a joke. You didn't have to answer that. :-P > I cannot predict "acceptable speed" requirements, but I can tell that > there will be some clients downloading 100MB report files from the > server, so I presume that I will need a progress bar. I think that I > need to develop my own protocol for this, and probably the underlying Okay, so you need to wrap large binary files in some kind of message, without pre processing them. I think developing your own protocol using XDR is a safe bet. > layer should use binary representation.>> Before I start re-inventing the > wheel: If you are worried about not reinventing the wheel, there are a couple of solutions I can think of. None of them seem to fully support you security and session management requirements, so you should estimate the required project/development time for them. - You may create a standard web application for that (with Django ?). Binary transfers simply use HTTP and have trivial overhead. You have to implement security and session management (cookies ?) on top of that. - Subclass BaseHTTPServer to implement a stateful and secure protocol. Again, binary transfers have trivial overhead. - If the goal of the project is to provide versioned file support, you could use a dpkg/apt (or RPM?) based installation system (it uses HTTP and FTP for file transfers). Write trivial front-ends in the client and the server and choose a secure HTTP server. - Finally, if you want to create your own protocol, but don't want to use XDR, you could to a similar thing using MIME based messages (the first message part is a XML message that references the binary attachments). > It is NOT the best way. Just to tell one example: big endian / little > endian integers. Definitely I need some encoding. Huh ? XDR does exactly that. > > (But if you are right and this is the best way, why would you avoid?) I would avoid packing/unpacking objects by hand. -- http://mail.python.org/mailman/listinfo/python-list