sorry for misunderstanding but what I really meant is : would it be impossible to have ONLY one API that is agnostic of VLT vs resource based?
regards antonio On Jul 24, 2013, at 10:23 PM, Robert Munteanu wrote: > On Wed, Jul 24, 2013 at 10:11 PM, Antonio Sanso <asa...@adobe.com> wrote: >> just taking a stab here , >> would it be impossible to have an API that is agnostic of VLT vs resource >> based? >> > > From a technical point of view it's possible, and that's why I tried > to separate things into API + implementation. > > I think that there is a concern that from a support / development > effort point of view it makes no sense to support two APIs at the same > time. On the long term we should (probably) pick one. > > But we also need to see which of those has the better IDE embedding > story, or at least we'll find out how to drive VLT towards better IDE > embeddability. > > Robert > >> regards >> >> antonio >> >> >> On Jul 24, 2013, at 7:54 PM, Robert Munteanu wrote: >> >>> On Wed, Jul 24, 2013 at 8:44 PM, Justin Edelson >>> <jus...@justinedelson.com> wrote: >>>> +1 to tooling and moving Maven stuff there. >>>> -0 to moving IDE out of the whiteboard until we have a consensus on a >>>> serialization/transport form. >>>> >>>> My understanding is that the current IDE codebase is being used to >>>> prototype a serialization form and transport protocol and that we will >>>> eventually be trying to reach consensus on using that, vlt, or something >>>> else. >>> >>> I've waited to propose move out of whiteboard until we had a solid >>> module structure which can be used to evolve the IDE stuff into what >>> we want it to be. >>> >>> The serialization form is more or less a draft which I'm using until >>> FileVault is accepted into Jackrabbit. The transport protocol is based >>> on the Sling HTTP Get/Post servlets, which is a de facto standard for >>> Sling applications, at least for those not using FileVault. >>> >>> The point here is that I don't have vlt to work with _now_ and I can >>> evolve the Eclipse mechanisms ( UI , servers, modules, change >>> detection ) - which are not trivial - without waiting for vlt. And I >>> can gather feedback from people brave enough to try it without waiting >>> for vlt. >>> >>> Once we can use VLT, we'll see what fits best. I admit that I have an >>> inclination towards the resource-based API, but it's not my personal >>> decision to make. >>> >>> Of course, I can put a hold on moving the codebase to trunk/tooling, >>> but that would not gain anything for now, since the codebase is in >>> flux anyway. >>> >>> Instead, my suggestion is not to make any sort of releases, not even >>> technology previews, until we have consensus on the VLT vs >>> Resource-based implementation. >>> >>> WDYT? >>> >>> Robert >>> >>>> >>>> An alternative would be to create the tooling top-level directory and then >>>> put the IDE in a branch. >>>> >>>> Justin >>>> >>>> >>>> On Wed, Jul 24, 2013 at 10:42 AM, Robert Munteanu <rob...@lmn.ro> wrote: >>>> >>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz >>>>> <bdelacre...@apache.org> wrote: >>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fmesc...@adobe.com> >>>>> wrote: >>>>>>> ...create a top level "tooling" (or so) folder and put the "ide" and >>>>> "maven" stuff in there ?... >>>>> >>>>> I've created [0] to track this move and will do that later on today - >>>>> lots of stuff to adjust in the poms under maven. >>>>> >>>>> Robert >>>>> >>>>> [0]: https://issues.apache.org/jira/browse/SLING-2978 >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from my (old) computer >>>>> >>> >>> >>> >>> -- >>> Sent from my (old) computer >> > > > > -- > Sent from my (old) computer
