Re: mapping [process|socket|...] to Filesystem
On Thursday 05 January 2006 12:12, Oliver Fromme wrote: Lou Kamenov [EMAIL PROTECTED] wrote: On 04/01/06, Oliver Fromme [EMAIL PROTECTED] wrote: [..] It would be much easier to use HTTP instead of (ab)using file system operations. Just install an Apache web server on your server machine and write a small CGI. The Windows clients can simply use a web browser to upload their data to your CGI. Then your CGI does whatever is necessary to communicate with your black box, and sends the result back to the client's web browser. representing different resources as files is not a new concept.. but rather an old one. look at plan 9. Right. Or look at devfs, procfs, fdescfs, portalfs etc. However, being able to represent resources or information via the file system does not necessarily mean that it is a particularly good idea to do so. For example, I think that procfs does not really make much sense. Especially Linux' procfs is a bad example of cramming too many things into the file system which do not belong there; it's just a big mess. It might be cool, it might be easy to do, so lets do it, but it's horribly inefficient and does not make sense. Another important point is the common guideline that as few things as possible should be implemented in the kernel. The kernel should provide interfaces to the hardware and to essential kernel facilities, but everything else should happen in userland. Richard is trying to implement a rather simple client-server mechanism to access a certain device on a server machine (I assume that there is already a driver for that device). There is no sane reason to do that on file system level. Handling it in userland is much more robust, easier to recover in case of problems, and easier to debug. Again, it was one of my original questions: 'is my idea simply stupid ?' And, yes, the communication via http is already working - nothing great. It was simply the idea to go one step further: wrap some of functions into kind of 'file-transfer' from the client's point of view. The idea (to me) still is tempting - but I will look at samba-vfs modules, possibly also fuse - which are clearly in userland. (I fully agree with the common guideline: as few as possible in kernel !) regards Richard -- Mit freundlichen Grüßen Richard Kästner EDV-Beratung Woerthgasse 17 2500 Baden Austria ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mapping [process|socket|...] to Filesystem
On Monday 02 January 2006 22:29, Björn König wrote: Richard Kästner schrieb: Hello, hope to find some help, hints and experience here: an external device expects commands and command data, it produces result-codes and result data. Communication is done via HTTP (and working) The idea is, to allow access via Samba, which requires either implementation of Samba - VFS modules or mapping to BSD-Filesystem - pseudofs came to my mind. [...] Hello, your description is a little bit vague to me, but it sounds like that this task can be probably done by using portalfs. See mount_portalfs(8) for examples. Regards Björn Björn, (sorry for being vague - I seem to be too deep in my problems) thanks for the tip - portalfs was the first thing to try, but it does not work with samba (at least the way, I wanted ): Portalfs does not allow to pass anything besides '/p/tcp/localhost/' To be less vague : the external device is a black box, communicates via ???-HTTP server. The idea is: - a (windows)user copies a file to a directory (say: .../commands/xyz), - there is a thing, that maps this file to some activity towards external box (similar to: procfs_doprocnote ) - as a response, a file appears in another file (.../response/data), which can be read from (windows)client ( similar to: procfs_doproccmdline) - the whole stuff should work diskless - response data can be from a few bytes up to several megabyte - if I can manage, I could export this filesystem via samba _and_ nfs ... - if it all was only about acces to the black box, it could be done via HTTP ... unfortunately, I have to deal with windows clients Regards Richard -- Mit freundlichen Grüßen Richard Kästner EDV-Beratung Woerthgasse 17 2500 Baden Austria ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mapping [process|socket|...] to Filesystem
On Tuesday 03 January 2006 20:20, Gary Corcoran wrote: Richard Kästner wrote: On Monday 02 January 2006 22:29, Björn König wrote: Richard Kästner schrieb: Hello, hope to find some help, hints and experience here: an external device expects commands and command data, it produces result-codes and result data. Communication is done via HTTP (and working) The idea is, to allow access via Samba, which requires either implementation of Samba - VFS modules or mapping to BSD-Filesystem - pseudofs came to my mind. [...] Hello, your description is a little bit vague to me, but it sounds like that this task can be probably done by using portalfs. See mount_portalfs(8) for examples. Regards Björn Björn, (sorry for being vague - I seem to be too deep in my problems) thanks for the tip - portalfs was the first thing to try, but it does not work with samba (at least the way, I wanted ): Portalfs does not allow to pass anything besides '/p/tcp/localhost/' To be less vague : the external device is a black box, communicates via ???-HTTP server. The idea is: - a (windows)user copies a file to a directory (say: .../commands/xyz), - there is a thing, that maps this file to some activity towards external box (similar to: procfs_doprocnote ) - as a response, a file appears in another file (.../response/data), which can be read from (windows)client ( similar to: procfs_doproccmdline) - the whole stuff should work diskless - response data can be from a few bytes up to several megabyte - if I can manage, I could export this filesystem via samba _and_ nfs ... - if it all was only about acces to the black box, it could be done via HTTP ... unfortunately, I have to deal with windows clients I'm just curious: why can't the windows clients just use Firefox (or any other browser) to access the black box? You can download files (e.g. results) with a browser... Gary As I wrote: it could be done via browser, but 1. it is a request 2. I became curious, if it is possible ... Richard BTW: I appologize, if I am cross-posting. Originally only posted to [EMAIL PROTECTED] Don't realize, how it appeared on freebsd-questions -- Mit freundlichen Grüßen Richard Kästner EDV-Beratung Woerthgasse 17 2500 Baden Austria ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly brief answers (was Re: Terminal Server)
[...sniped...] Disrearding any pro's and con's for the discussion: as a 'consumer' of this list, I want to say thanks for much valuable information I received from this list! Sure, many questions are somewhat ... well, could have been better worded However, even wrong answers gave me a lot of info! (And I hope, there will be the same spirit in future) Thanks to all the helping hands! -- Mit freundlichen Grüßen Richard Kästner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
