Re: [Erlyaws-list] WebDAV - more than file access

[Torbjorn T. <to...@no...>]

Reto Kramer wrote:
> Hi Torbjorn,
> 
>> My approach has been to change as little as possible of the
>> existing code.
> 
> 
> Sounds like the way to go - I much prefer your elegant way to hook into 
> yaws over my hack.
> 
>> To see my changes to the Yaws code, you can run:
>>
>> cvs diff -r 1.278 yaws_server.erl
>> cvs diff -r 1.89 yaws.erl
>>
>> As you can see, I'm adding DAV stuff incrementally as I need them.
>>
>> The basic idea is to have the code, which is making use of WebDav
>> in an AppMod. So for example, I've started to implement a filesystem 
>> layer, which at the moment supports: PROPFIND, MKCOL, PUT, DELETE and 
>> GET. Check out the file dav.erl to see how it works.
> 
> 
> Got it to work fine with cadaver and a few changes should do the trick 
> of OSX's webdav_fs.
> 
> I can easily port my /proc sample to the AppMod approach.
> 
> My one concern at this point - and this is easy to resolve - is that 
> each dav style AppMod will duplicate the knowledge about dav return 
> codes, dav response formats etc (and I expect there to be quite some, 
> imagine e.g. "echo 1>eproc/yaws/debug_enabled" ;-).  I can centralize 
> this for my projects, but perhaps we should add a helper module that can 
> be leveraged by everyone (or add to yaws_dav). 

Yes, that is probably a good idea. This is easier to do when you
have at least two applications so that you can identify the
parts of the code they have in common. Since you now have such
a second application, feel free to move code of general use into
e.g yaws_dav.erl.

>  The uses I have in mind 
> all return either {ok, ListOfTuples} | failed, which can then be turned 
> into the appropriate dav response depending on the http/dav-method that 
> was invoked.
> 
>> I'm also thinking of implementing a SMB browser similar to 'Davenport'
>> which would make it possible to open up WebFolders in Internet Explorer.
> 
> 
> Great! I'd like to be able to write my modules, so that I can expose 
> hierarchical information via http (read only, but allows curl 
> http://..., webdav as well as smb).  Are you planning to take a similar 
> approach to what you did with dav and require an AppMod to essentially 
> be a protocol bridge?  If so, are you going to introduce fake http 
> methods?  I'm asking, so I can understand how I would bridge smb based 
> access to my /proc like modules.

Yes, I will have an AppMod which implements the bridge to an SMB
server. What do you mean by 'fake http methods'? A user friendly
approach is of course to have the SMB file path in the URL, example:

http://localhost/smb/<host>/<share>/<path>

The problem is to handle the authentication. You need to use
a cookie to make successive calls possible. Another problem
is the handling of multibyte characters. I will look into
the mount.davfs approach to see what kind of DAV operations
it generates. On Gentoo Linux I have something called davfs2,
which seem to make it possible to give username/password:

mount.davfs -o username=bill,password=secret http://localhost 
/smb/<host>/<share>

Could be fun!

Cheers, Tobbe

> 
>> If I'm not mistaken, I think your 'dispatcher layer' is the same
>> as the AppMod idea I described above?
> 
> 
> Yep! I find this very elegant.
> 
>> I have also started to make use
>> of the xmerl application to parse and create XML.
> 
> 
> Again, much nicer than my experiment!
> 
>> This makes it possible
>> to create a datastructure (similar to ehtml) and have it expanded into 
>> XML. A simple interface is located in yaws_dav.erl and you can see in
>> dav.erl how I'm using it.
> 
> 
> Here is where I'd like yaws_dav to perhaps be the helper I mentioned 
> above. The dav module in my mind should be called dav_fs and all 
> knowledge of dav protocol specific return codes and xml to wrap around 
> responses be moved to yaws_dav. In this way multiple dav_XYZ AppMods can 
> be added without duplication of dav protocol specific code.
> 
> Examples would be:
>   dav_fs        - filesystem access
>   dav_erlproc        - Erlang vm and application information (incl. 
> control over simple tracing patterns)
>   dav_yawsproc    - control and monitoring of a yaws instance
> 
>> I guess it is ok to add your stuff right into the CVS (if you have
>> commit rights) as long as you are careful with the changes to 
>> yaws_server.erl and friends.
> 
> 
> Thanks for this invitation!
> 
> - Reto
> 
>>
>> Cheers, Tobbe
>>
>>
>> Reto Kramer wrote:
>>
>>> I'm very much interested in the webdav support that started to appear 
>>> in 1.55. I'm using webdav as a protocol to expose all sort of 
>>> hierarchical information, not just the actual files on a real disk. 
>>> It's ideal to e.g. create a /proc type file system. In that sense 
>>> webdav makes it easy to create a "modern" version of Luke's "enfs" 
>>> project nfs_procfs (see jungerl).
>>> My suggestion is to introduce a "dispatcher" layer that allows me to 
>>> associate handlers with url prefixes. E.g. I could then register an 
>>> "/erlproc" path to associate itself with a bunch of code that exposes 
>>> erlang internals (just for kicks). Other handlers might want to 
>>> expose application configuration values (.app) ... you get the idea, 
>>> I'm sure.
>>> Exposing actual files on disk would then become just yet another 
>>> handler.
>>> I've gotten pretty far with extending 1.48 towards this goal last 
>>> year (before other work hit me). Below is a snapshot. The .patch file 
>>> includes the changes I made to the core yaws server to hook in the 
>>> yaws_davdisp module as the dispatcher layer. You'll see that in this 
>>> experiment the dispatcher calls the yaws_davproc handler. The 
>>> association is at the root of the mounted tree (i.e. /proc, see 
>>> yaws_davdisp:lookup_dav_handler/1).
>>> I call this an experiment since there's a lot of work still to be 
>>> done (see the FIXME comments), but now that I realize that at least 
>>> one more person is interested in webdav support, I'm getting more 
>>> energized about spending my nights on it again ;-).
>>> Before too much of Tobbe's time goes into it, I hope we can add the 
>>> dispatcher layer.
>>> This version works on OSX all right. It does not currently work with 
>>> Windows and a quick cadaver trial shows problems, lots of experiments 
>>> around dav is how I learnt to make it work on the Mac.
>>> Currently, callbacks work for
>>> - ls
>>> - rm
>>> - rd (i.e. cat, etc.)
>>> - wr (i.e. echo, etc.), I fake the locking, works great :-)
>>> - mkdir
>>> I've not played with move and copy much yet.
>>> To give you a taste:
>>> $ touch proc
>>> $ mount_webdav localhost:8000/proc proc; echo $?
>>> $ ls proc/NODE/nonode\@nohost/
>>> APP-LOADED APP-RUNNING MODULE PID
>>> $ cd proc/NODE/nonode\@nohost/
>>> $ ls
>>> 0.0.0 0.20.0 0.37.0 0.50.0 application_controller kernel_sup
>>> 0.10.0 0.21.0 0.38.0 0.51.0 code_server rex
>>> 0.11.0 0.22.0 0.4.0 0.53.0 ddll_server ssl_broker_sup
>>> 0.12.0 0.23.0 0.42.0 0.54.0 erl_prim_loader ssl_server
>>> 0.13.0 0.24.0 0.43.0 0.55.0 error_logger ssl_sup
>>> 0.14.0 0.25.0 0.44.0 0.56.0 file_server user
>>> 0.15.0 0.31.0 0.45.0 0.57.0 file_server_2 yaws_log
>>> 0.16.0 0.32.0 0.46.0 0.58.0 global_group yaws_server
>>> 0.17.0 0.33.0 0.47.0 0.60.0 global_name_server yaws_session_server
>>> 0.18.0 0.34.0 0.48.0 0.7.0 inet_db yaws_sup
>>> 0.19.0 0.35.0 0.49.0 0.8.0 init
>>> 0.2.0 0.36.0 0.5.0 0.9.0 kernel_safe_sup
>>> $ cat PID/0.0.0
>>> [{registered_name,init},
>>> {current_function,{init,loop,1}},
>>> {initial_call,{otp_ring0,start,2}},
>>> {status,waiting},
>>> {message_queue_len,0},
>>> {messages,[]},
>>> {links,[<0.4.0>,<0.5.0>,<0.2.0>]},
>>> {dictionary,[]},
>>> {trap_exit,true},
>>> {error_handler,error_handler},
>>> {priority,normal},
>>> {group_leader,<0.0.0>},
>>> {heap_size,610},
>>> {stack_size,2},
>>> {reductions,5514},
>>> {garbage_collection,[{fullsweep_after,65535}]}]
>>> cheers,
>>> - Reto
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
>> shotput
>> a projector? How fast can you ride your desk chair down the office 
>> luge track?
>> If you want to score the big prize, get to know the little guy.  Play 
>> to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>> _______________________________________________
>> Erlyaws-list mailing list
>> Erl...@li...
>> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>>
>