Re: Off topic: The Adobe deal
Hi Mike, we have no intention to change anything in Day's commitment and contributions to Sling and Jackrabbit. I think it is all good news. Please read Adobe's Erik Larson's comment on: http://www.computerworlduk.com/community/blogs/index.cfm?blogid=14&entryid=3098 regards, david On Wed, Jul 28, 2010 at 2:57 PM, Mike Müller wrote: > Hi > > WDYT about the Adobe deal in particularly with regards to > the involvement in the open source projects like Sling and > Jackrabbit? Is it good news or bad news? > > best regards > mike > -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @davidnuescheler
Re: multi-workspace support in script resolution
Hi Justin,
thanks a lot for your swift response.
> I think the subject of this thread is slightly misleading... it really
> should be "scripts should be resolved from the same workspace as
> resources". Which is essentially the summary of SLING-1446.
ahhh ok, that definitely makes more sense...
>> They are not for separating things out, like user A has a workspace
>> and user B has
>> a workspace, they are also not for separation by type.
> I have to stop you there. user-specific workspaces seem like a perfectly
> legitimiate use of workspaces IF those users are editing the same
> content tree.
Agreed. Which would make in turn use of merge() update() and clone() ;)
> Imagine four workspaces:
> 1) user1
> 2) user2
> 3) trunk
> 4) publish
> A node is created in user1 at /content/index, then clone() is called in
> trunk [i.e. clone("user1", "/content/index", "/content/index", false)].
> The node is then cloned into user2 [i.e. clone("trunk",
> "/content/index", "/content/index", false)]. User2 makes some changes in
> their workspace, saves, and then updates the node in trunk
> [node.update("user2")]. Finally, the node is clone from trunk to publish
> and is user-facing.
> The key point I've understood about workspaces and their appropriate use
> is that workspaces are supposed to represent the same content tree.
> Having private working copies doesn't seem to violate this.
Absolutely. I agree with you. Maybe I should clarify that in the wiki...
I was mostly referring to a usecase of multi-tenancy that people sometime
mistake as a good usecase for workspaces.
> By the by, something to consider for JCR 3 is that clone/update/merge
> all operate from the perspective of the "target" workspace (i.e. the
> workspace being cloned into, updated, merged). For promotion workflows,
> I believe corresponding methods called from the source workspace/session
> would be more natural, similar to how "git push" works.
Hmm... Good point. Maybe even JCR 2.1.
I think the issue is that to make modification in a workspace other than the
one that you have a session to is something that we lack some machinery
for...
thanks for the follow-up.
regards,
david
Re: multi-workspace support in script resolution
I just saw the topic of this thread and thought i would like to weigh in on this conversation... Workspaces are just about one of the most frequently abused feature of JCR and I have a feeling that this thread may forget what workspaces are for. Workspaces are for .clone(), .merge() and .update() [1] They are not for separating things out, like user A has a workspace and user B has a workspace, they are also not for separation by type. Usually when people use workspaces without using merge, clone or update they usually want to either use Access Control and the hierarchy or separate repositories. Workspaces are not a good solution for either of the two. regards, david [1] http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.
Re: Runmode support for /etc/map configuration
here is my take on the exact use case that we have with the runmode aware /etc/map it is probably seldomly the case that we actually have different mappings it is just that hostname get into our way. in the classic wcm authoring or development environment one would still like to see urls that are as close as the ones that we have in production but of course we would not like the links to be rewritten to go fully qualified urls with a domain name... so generally i think the /etc/map tree will look very similar from runmode to runmode but in one every other runmode other than production i would probably either want to put the domain name somewhere in to the url that indicates to the user that this would be a link that would go to http://www.example.org/test in production. so probably could be resolved to something like http://mydev/www.example.org/test . keep in mind though that usually there are only going to be very few link where that would actually make a difference since this assumes that an application has cross domain links under management within one sling instance. to be perfectly honest, for our commercial solution, i think we can do perfectly without the runmode aware /etc/map regards, david On Thu, Dec 10, 2009 at 9:05 PM, Felix Meschberger wrote: > Hi, > > Bertrand Delacretaz schrieb: >> On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger >> wrote: >>> ...So, I will go for option (1): make the /etc/map location configurable >> >> Note that it would be good to be able to find the actual value used >> easily, for example via a console plugin and/or INFO log messages. > > Yes, makes sense. > > Regards > Felix > >> >> -Bertrand >> > -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
Re: script resolution by hostname ?
hi markus, it was brought to my attention, that i forgot to mention the sharing of content amongst websites as a use case so i would like to clarify the below statement a little bit more in detail... > if you assume that you have separate content trees but would like to > share the applications or the security (the users) it is perfectly > feasible to run things off of one sling instance. if you want to share "content" (in the broader sense) amongst sites, including "website content", "apps", "config", "users" or anything else stored in the repository, you possibly want to use one single sling instance. as a rule of thumb i would say that the more you share, the higher the chances of a shared sling instance. isolation makes sense in the "hosting" usecase where you have different customers that (must) share nothing. regards, david
Re: script resolution by hostname ?
hi markus,
in my experience running different websites (for the lack of a better
term) in an environment is really a matter of isolation/separation
between the instances.
if you assume that you have separate content trees but would like to
share the applications or the security (the users) it is perfectly
feasible to run things off of one sling instance.
if you want to reach a greater isolation like running multi websites that
are completely separate i usually recommend to run things off of
different sling instances. even different jvm instances.
especially if you would like to have a degree of isolation where
a programming mistake in one website (let's say a "while(true){}")
does not impact the other websites i would definitely advocate separate
jvms.
really the cost of running a separate sling instance is a little bit of
disk-space and a few dozens of megabytes of heap.
regards,
david
2009/8/26 Alexander Klimetschek :
> On Wed, Aug 26, 2009 at 5:58 PM, Markus Pallo wrote:
>> The use case is each site has custom content which should not reflect to
>> others.
>>
>> And there is a news provider prvoviding news which both sites should use and
>> modification on these news should reflect on all sites immediatly.
>>
>> So probably we could have three content trees domain1, domain2, shared.
>
> Right, that's how it is typical.
>
>> If we have two or three different content trees in the same repository, how
>> to configure resource search path that the scripts will be found for the
>> corresponding content tree (site layout) ? The nodes have same
>> sling:resourceType.
>
> Well, they should have a different resource type then. Or, in cases
> where it makes sense, you can make the behaviour of scripts depending
> on the domain.
>
> But in general, in a CMS/webapp scenario, you want to reuse your
> scripts (or "components") with different content, not the other way
> around. Changing content is easier than developing new scripts and/or
> duplicating scripts.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetsc...@day.com
>
--
David Nuescheler
Chief Technology Officer
mailto: david.nuesche...@day.com
web: http://www.day.com/ http://dev.day.com
twitter: @daysoftware
