You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Angela Cymbalak <a....@nechtan.org> on 2008/07/01 14:27:09 UTC
question re: Noel's idea for no rigid backend for photogallery
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@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: question re: Noel's idea for no rigid backend for photogallery
Posted by Carsten Ziegeler <cz...@apache.org>.
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@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: question re: Noel's idea for no rigid backend for
photogallery
Posted by Angela Cymbalak <a....@nechtan.org>.
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@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Photogallery project ideas and mailing list
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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@incubator.apache.org, 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@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org