question re: Noel's idea for no rigid backend for photogallery

[Angela Cymbalak]

Noel,

Can you dive into the idea a little more about not providing a
backend storage mechanism for the photo gallery?  Wouldn't JCR give
you the option of not having a rigid backend but be more
flexible?  If you provide interfaces, what would they interface with
on the backend?  Maybe all these questions are just because I haven't
had my coffee yet this morning but my brain is just not wrapping
around the idea.

Angie



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Angela Cymbalak]

Sorry for the flood of emails this morning.   I answered my own
questions.  Thinking abstractly before 8:45 AM hurts my head...

I think the answer to the question should we provide a rigid backend
structure or just an interface is a good question.  And I think that
the answer is a qualified both.

In order to correctly provide a rigid backend structure you have to
write an interface to it.  When starting from scratch that interface
can be anything.  If it is designed in such a  way to be flexible
then releasing it is no big deal.  This is the perfect solution for a
larger enterprise.  They normally already have a structure that they
need your code to fit into, not the other way around.  However, just
as Carsten has done with Sling, it wouldn't be unheard of to then
write a complete implementation around your interfaces that has a
more rigid storage  structure.  This could then be released as a
subproject.  It could either be an example or for those who need it,
a fully functioning application.

Angie

At 08:27 AM 7/1/2008, you wrote:

>Noel,
>
>Can you dive into the idea a little more about not providing a
>backend storage mechanism for the photo gallery?  Wouldn't JCR give
>you the option of not having a rigid backend but be more
>flexible?  If you provide interfaces, what would they interface with
>on the backend?  Maybe all these questions are just because I
>haven't had my coffee yet this morning but my brain is just not
>wrapping around the idea.
>
>Angie
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@...
>For additional commands, e-mail: general-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Carsten Ziegeler]

Angela Cymbalak schrieb:

> Sorry for the flood of emails this morning.   I answered my own
> questions.  Thinking abstractly before 8:45 AM hurts my head...
>
> I think the answer to the question should we provide a rigid backend
> structure or just an interface is a good question.  And I think that the
> answer is a qualified both.
>
> In order to correctly provide a rigid backend structure you have to
> write an interface to it.  When starting from scratch that interface can
> be anything.  If it is designed in such a  way to be flexible then
> releasing it is no big deal.  This is the perfect solution for a larger
> enterprise.  They normally already have a structure that they need your
> code to fit into, not the other way around.  However, just as Carsten
> has done with Sling, it wouldn't be unheard of to then write a complete
> implementation around your interfaces that has a more rigid storage  
> structure.  This could then be released as a subproject.  It could
> either be an example or for those who need it, a fully functioning
> application.
>

Just my 2 cents on this issue: I don't know if its a good idea to
provide an interface
for the backend and allow to exchange the backend using this interface.

But while this seems to be appealing from a pure architectual point of
view, it has the drawback that this interface has to be defined
accordingly *and* implemented which might be a major task. So,
personally I would start simpler, e.g. with an existing api and impl
(like JCR) and then get feedback and experience if something more
abstract is required. This could be something for a 2.0 version :)

Carsten
--
Carsten Ziegeler
cziegeler@...

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[JAMES Nightly Build System]

> Can you dive into the idea a little more about not providing a
> backend storage mechanism for the photo gallery?

Actually, it isn't an idea.  I was simply asking a question of where the
project will "hang its hat(s)" and where it will be flexible.  What are its
defining points, and where is it open to multiple options?

> Wouldn't JCR give you the option of not having a rigid backend but be more
> flexible?

JCR, while it can use multiple storage backends, still sets the data model,
i.e., it would be a JCR-based content repository, not (for example) a
relational database model.

It seems to me that the surface of the project at least starts with:

  - URI design (REST interface)
  - Content Model
  - Interface API (for non-REST access)

If people want to discuss this further, why don't we move the discussion
from general@ to projects@..., where it can simmer until
people are ready to call for a vote?  That should alleviate your concern
about wanting to have in-depth discussion without unduly burdening the
general list.

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...