two doors in Lenya was: Re: webdav support commited

[Doug Chestnut <dh...@virginia.edu>]

Torsten Schlabach wrote:
> I am not sure if it will be a good idea to introduce more and more tricks
> and exceptions to the Lenya URI space, such as
> 
> /dav/xyz
> 
> for WebDAV access to
> 
> /xyz
> 
> I think the problem is that we have one entry point that we talk to (the
> top level sitemap) and we try to get very different things out of it, such
> as
> 
> - fully rendered live view
> - authoring view (WYSWYG)
> - editable version of a document (for Kupu and BXE)
> - WebDAV version
> - ...
> 
> I'd feel much better if we had two doors into Lenya: One for rendering
> (site visitor facing) and one for editing purposes (internally, site
> builder team facing). This would especially offer a very clean way to shut
> the "editing" door in live environments.
> 
> WDYT?

Sounds like a good idea.  What should the door be?
Currently, that "door" is in the path, right?
ex: /default/authoring/features.html or /default/live/features.html

Are you talking about doors as separate instances of lenya?:
http://localhost:9999/default/features.html (authoring)
http://localhost:8989/default/features.html (webDAV)
http://localhost:9898/default/features.html (OSR-101)
http://localhost:8888/default/features.html (live) or
http://webserver:8888/default/features.html (live on another box sharing 
repo)

perhaps I am way off base ;)


> 
> Regards,
> Torsten
> 
> 
>>Renaud Richardet wrote:
>>
>>>Torsten Schlabach wrote:
>>>
>>>
>>>>>I've been experimenting with Cadaver and Vim, and it worked OK.
>>>>>
>>>>
>>>>
>>>>With 1.4alpha1 or with a recent SVN version?
>>>>
>>>>
>>>
>>>With a recent SVN. The basic editing with VIM worked very well.
>>>
>>>BTW: has anybody tried OpenOffice as a WebDav client? I can open the url
>>>http://localhost:8888/default/ but get the login page. I found no way to
>>>pass the username and pwd so far.
>>
>>I have tried OpenOffice and have the same problem.  Open Office doesn't
>>pass a user-agent header
>>(http://www.openoffice.org/issues/show_bug.cgi?id=21599).
>>
>>The webDAV usecases in 1.4 use the method in place of a lenya.usecase
>>parameter.  This works great for all but the GET method which is also
>>used in the authoring area by a web browser.  This is one of the reasons
>>  for matching the user-agent header.  The other reason is to
>>authenticate via basic auth instead of the web form that lenya provides.
>>
>>These problems could be resolved by using the path to differentiate a
>>webDAV client ( GET /dav/default/authoring/index.html ).  Changing the
>>path would cause problems with the page-envelope module (and usecases
>>that use it?).
>>
>>I will double check, but in testing a few webDAV clients, it didn't
>>appear that they like redirects, sessions, or GET parameters.
>>
>>--Doug
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: two doors in Lenya was: Re: webdav support commited

[Torsten Schlabach <ts...@apache.org>]

Doug,

> Sounds like a good idea.  What should the door be?
> Currently, that "door" is in the path, right?
> ex: /default/authoring/features.html or /default/live/features.html
>
> Are you talking about doors as separate instances of lenya?:
> http://localhost:9999/default/features.html (authoring)
> http://localhost:8989/default/features.html (webDAV)
> http://localhost:9898/default/features.html (OSR-101)
> http://localhost:8888/default/features.html (live) or
> http://webserver:8888/default/features.html (live on another box sharing
> repo)
>
> perhaps I am way off base ;)

No, you are not off base at all!

This is exactly what I meant, except that different ports are one
possible solution while subdomains would be another one, for example:

> http://authoring.server.com/default/features.html (authoring)
> http://dav.server.com/default/features.html (webDAV)
> http://www.server.com/default/features.html (live) or

In real live I guess the requirement usually would be to have in live
mode one domain such as www.company.com point to one publication (the
company's website) with clean URLs such as
http://www.company.com/index.html. You don't really want
http://www.company.com/lenya/company/live/index.html. Today we do a lot
of tricks (reverse proxies, mod_rewrite, etc.) to map
http://www.company.com/lenya/company/live/index.html to
http://www.company.com/index.html, it it is very easy to get it wrong.

And if you get this wrong for a public site, it can have quite severe
side effects such as Google indexing the authoring branch of the site.
It will not be able to log in, but the fact that there is an entry to
the authoring area will be publicly revealed. Probably to anyone who is
searching for your company's name.

I know of larger corporations who's IT security policies would require
that the authoring part of the CMS is clearly separated from the live
rendering portion and lives on a separate server and that the authoting
part is not even installed on the live machine in the DMZ. (And we are
targeting enterprises with Lenya, don't we.)

Key to sorting this out would probably be a proper repository, as it is
slowly evolving with JCR integration into Lenya. As you suggested, the
live server and the authoring server can just share the same repository
and that's it. It might then also be possible to create a live-only
one-publication edition of Lenya which will render just one publication
under one domain from a given repository path.

I would just warn against too many URI conventions. If you rely on the
/publication/area/... kind of thing *inside documents* (links, pictures,
etc.) you will have a hard time rendering the publication if it has to
live outside of /publication/area but in /. And there is tons of stuff
you probably don't think about in the first place, such as editors
creating links and putting in pictures for example.

Quickly coming back to the multiple doors idea:

This could still live inside the same instance of Cocoon if it would be
possible to use any kind of Cocoon selector. The HostSelector might be a
good candidate if you just create aliases for different hostnames all
pointing to the same physical instance of Cocoon. This is how Apache
httpd does virtual hosting at host ISPs.

It would be important to have the Selector select on something that
clients are as agnostic to as possible. As we learn from WebDAV,
parameters, request methods, probably also sessions or Cookies probably
don't make good candidates.

Regards,
Torsten

Doug Chestnut schrieb:
> 
> 
> Torsten Schlabach wrote:
> 
>> I am not sure if it will be a good idea to introduce more and more tricks
>> and exceptions to the Lenya URI space, such as
>>
>> /dav/xyz
>>
>> for WebDAV access to
>>
>> /xyz
>>
>> I think the problem is that we have one entry point that we talk to (the
>> top level sitemap) and we try to get very different things out of it, 
>> such
>> as
>>
>> - fully rendered live view
>> - authoring view (WYSWYG)
>> - editable version of a document (for Kupu and BXE)
>> - WebDAV version
>> - ...
>>
>> I'd feel much better if we had two doors into Lenya: One for rendering
>> (site visitor facing) and one for editing purposes (internally, site
>> builder team facing). This would especially offer a very clean way to 
>> shut
>> the "editing" door in live environments.
>>
>> WDYT?
> 
> 
> Sounds like a good idea.  What should the door be?
> Currently, that "door" is in the path, right?
> ex: /default/authoring/features.html or /default/live/features.html
> 
> Are you talking about doors as separate instances of lenya?:
> http://localhost:9999/default/features.html (authoring)
> http://localhost:8989/default/features.html (webDAV)
> http://localhost:9898/default/features.html (OSR-101)
> http://localhost:8888/default/features.html (live) or
> http://webserver:8888/default/features.html (live on another box sharing 
> repo)
> 
> perhaps I am way off base ;)
> 
> 
>>
>> Regards,
>> Torsten
>>
>>
>>> Renaud Richardet wrote:
>>>
>>>> Torsten Schlabach wrote:
>>>>
>>>>
>>>>>> I've been experimenting with Cadaver and Vim, and it worked OK.
>>>>>>
>>>>>
>>>>>
>>>>> With 1.4alpha1 or with a recent SVN version?
>>>>>
>>>>>
>>>>
>>>> With a recent SVN. The basic editing with VIM worked very well.
>>>>
>>>> BTW: has anybody tried OpenOffice as a WebDav client? I can open the 
>>>> url
>>>> http://localhost:8888/default/ but get the login page. I found no 
>>>> way to
>>>> pass the username and pwd so far.
>>>
>>>
>>> I have tried OpenOffice and have the same problem.  Open Office doesn't
>>> pass a user-agent header
>>> (http://www.openoffice.org/issues/show_bug.cgi?id=21599).
>>>
>>> The webDAV usecases in 1.4 use the method in place of a lenya.usecase
>>> parameter.  This works great for all but the GET method which is also
>>> used in the authoring area by a web browser.  This is one of the reasons
>>>  for matching the user-agent header.  The other reason is to
>>> authenticate via basic auth instead of the web form that lenya provides.
>>>
>>> These problems could be resolved by using the path to differentiate a
>>> webDAV client ( GET /dav/default/authoring/index.html ).  Changing the
>>> path would cause problems with the page-envelope module (and usecases
>>> that use it?).
>>>
>>> I will double check, but in testing a few webDAV clients, it didn't
>>> appear that they like redirects, sessions, or GET parameters.
>>>
>>> --Doug
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>> For additional commands, e-mail: dev-help@lenya.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org