2009/7/6 Lars Hamren <[email protected]>: > As I need to write a new server implementation, I have looked > at the existing servers. > > As far as I understand it, fcgi/* and http/* both implement the class > WServer and the function WRun(), and are placed in different > libraries: libwtfcgi and libwthttp, only one of which can be linked > into the application. >
Correct > I suggest making WServer an abstract base class and adding concrete > classes like FcgiServer and HttpServer. This would not change any > existing code outside the server directories, but would make the > code more obvious. > Ok, this is acceptable. > Later on, with this implementation, adding factories and a > factory-lookup function would make it possible to choose server type > at run time. > That would be a nice feature, but this is also where we may have a few practical problems we to solve. Currently there are three libraries: wt, and the two connectors: httpd and fcgi. Imagine that we move WRun from the connectors to Wt. If we want to have a system where we can decide at runtime which connector we want, the connectors have to somehow let the wt library know that they are available. So what can we do about this? - Use dlls for the connectors, and let wt (from within WRun) load them dynamically with dlopen(), and populate the factory based on the dlls we find. The setup/installation of Wt would be complicated because Wt needs to find the connector DLLs in some predifined path. Advantage: WRun moves into wt.so and you can specify the server type by a parameter to WRun or in a config file. - Link all the connectors into the wt.so. Also not ideal, because we still don't have a system that can be extended by other connectors, like you want to do. Also, as certain connectors are optional, I like it that they are not part of the wt library (this could lead to a large amount of types of libwt.so). On the other hand, like the previous solution, connectors could be decided upon at runtime. - Modify the WRun API and let the user of the library instantiate the connector. As such we don't need the connector factory anymore, the library user does the work. This would work, with as disadvantage that the user needs to do some extra work. - Others? Would there be a reliable, portable solution that uses DllMain/_init/__attribute__((constructor))? Not sure for now, but we're open for suggestions. > I would be happy to have a stab at implementing this, if I knew that > the changes, if successful, will be accepted. > Ok for the abstract class stuff, and I'm curious to hear your solution for the factory. If there's no acceptable solution for the latter, the abstract class stuff is an aesthetic change only that we would probably accept anyway. Best regards, Wim. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
