Re: [prov] ECF in P2, was request handler orientation

I admit I'm a little confused by this thread, as it seems bring up a 
range of issues...some of which are related to ECF functionality and 
some of which don't seem (to me) to be directly related to ECF per se 
(but rather the provisioning request handlers?).

RE: Stefan's original comments about the ECF proxy handling and 
authentication structure...the API supports both proxy and arbitrary 
auth mechanisms for whatever protocol/provider implementation is used 
for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF 
exposes extension points for adding support for other protocols (e.g. 
private ones like a repository-specific protocol).

RE: defining request handlers externally...I think the current version 
of ECFHandler (version I looked at few weeks ago anyway) is overly tied 
to a *particular* (default) protocol/provider (http via URLConnection).  
I think this handler could be abstracted and made pluggable, but I 
haven't yet given much thought to how this would be done as I'm not yet 
familiar enough with all the provisioning code to understand the 
external API requirements on request handlers.

Pascal Rapicault wrote:
> In scenarios where size matters, or where only one well-known transport is
> to be used, the handler give us the ability to remove our dependency on
> ECF.
> So to me, to know whether or not the handler should be kept, we have to
> answer the following questions:
>
> * Size
> - Is ECF small enough for scenarios where size matters?
>   

Re: [prov] ECF in P2, was request handler orientation

Thanks for all the comments and info Scott (and others).  First, this thread started with something completely unrelated to ECF.  I was just interested in whether the call to RequestHandler.download() happen in the MirrorRequest or somewhere in the ArtifactRepository (or elsewhere).  In the end I think that that has been resolved and the call will be moved as I restructure some of the code.

As for using ECF, I am all for using it and so far have not found it to be particularly limiting or limited.  If it were then I expect that we would work with you to understand how we should use it or to enhance it to suit the requirements.  For example, my recent questions about chaining InputStreams.  Given your advice I am going to revisit the approach I proposed and Stefan implemented to see if we can flip it around to use OutputStreams and have ECF *push* data through the pipe rather than having clients *pull* data out of the pipe.  Should be resaonbly straightforward as this is what Stefan had originally (sorry Stefan  Anyway, having said that, depending on how complex this gets, it may be worth our will to still maintain an insulating later between p2 and whatever handler technology we are using.  Your points about potential complexity here are well taken and that will have to weigh into the consideration.

There is a valid question of whether or not we expose handlers and ECF in the p2 API.  We would do well to avoid it if possible.  Not because there is anything wrong with ECF rather if we can implement p2 without exposing ECF then it is likely simpler as there would likely be less API and fewer concepts.  Of course, that might come at the expense of flexibility...  We will have to see.

Finally, we will certainly take you up on your offer of assistance in structuring the handler code and other bits.   Thanks

Jeff
 

Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org> Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org 08/31/2007 09:20 PM Please respond to Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> cc Subject Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

I admit I'm a little confused by this thread, as it seems bring up a
range of issues...some of which are related to ECF functionality and
some of which don't seem (to me) to be directly related to ECF per se
(but rather the provisioning request handlers?).

RE: Stefan's original comments about the ECF proxy handling and
authentication structure...the API supports both proxy and arbitrary
auth mechanisms for whatever protocol/provider implementation is used
for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF
exposes extension points for adding support for other protocols (e.g.
private ones like a repository-specific protocol).

RE: defining request handlers externally...I think the current version
of ECFHandler (version I looked at few weeks ago anyway) is overly tied
to a *particular* (default) protocol/provider (http via URLConnection).  
I think this handler could be abstracted and made pluggable, but I
haven't yet given much thought to how this would be done as I'm not yet
familiar enough with all the provisioning code to understand the
external API requirements on request handlers.

Pascal Rapicault wrote:
> In scenarios where size matters, or where only one well-known transport is
> to be used, the handler give us the ability to remove our dependency on
> ECF.
> So to me, to know whether or not the handler should be kept, we have to
> answer the following questions:
>
> * Size
> - Is ECF small enough for scenarios where size matters?
>  

What would be considered 'small enough'?  I know zero bytes of code is
best :), but that seems a little 'severe'.  Of course ECF's pluggable
transport nature could be sacrificed and a return to the JRE-provided
URLConnection could be used instead, but this returns things to the
state prior to the equinox provisioning work (i.e. bound to a specific
transport...e.g. http).

I guess I'm not clear on what benefit removing the dependency on ECF
would have other than a fairly small change in code size, and it's costs
(return to lack of flexibility in transports) would be pretty clear.  
Besides, what's the problem?

> - Can the removal of the dependency on ECF be achieved by another way (for
> example having a new DownloadManager)?
>
> * Pluggability
> - Can any transport be plugged into ECF, if not what is missing from the
> API?
>  

This is a very important question.  I would assert than any file
transfer protocol of interest can be plugged into the ECF filetransfer
API...but if this turns out to be wrong for some transport and API
changes (as opposed to additions) are needed, then I would like to know
about that as soon as possible.

> - How more complex would the handler have to become, which other
> infrastructure would we have to have when ECF is not present (e.g. how do
> we know which transports are supported)?
>  

I would guess that the handler would have to become significantly more
complex without ECF, because if multiple/pluggable transports are
desired/required then *some* abstraction has to be introduced to provide
pluggability/flexibility at the transport level.  ECF is essentially
that abstraction.

> - How complex is it to plug a new transport?
>
> * Functionality
> - What does ECF brings us?
>  
I would offer that it provides a consistent API to get pluggable file
transfer protocols, suspendable/resumeable transfers, and other goals
for transport pluggability as described here

http://wiki.eclipse.org/Equinox_Provisioning_Plan

...and probably other places.

> - Will ECF be able to overcome its current limitations? Is the ECF team
> aware of these?
>  
RE: the current (implementation) limitations WRT proxy handling...we have:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286

Beyond these, I'm not exactly clear on what people are suggesting are
the limitations of ECF API or specific protocol implementations.  If
there are specific limitations (outside the proxy issues) that I/we
should know about then I would appreciate bug and/or enhancement
requests.  We are completely able and willing to address any such
limitations as they are identified.

> Can any one take a look at this?
>  

By take a look at this do you mean looking at
redesigning/reimplementing/generalizing the provisioning request handler
(ECFHandler as current impl) structure or something else?  In either
case, I can probably contribute if that's desired.  But I would like to
understand better what the current deficiencies are (beyond full impl
support for proxy handling).

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [prov] ECF in P2, was request handler orientation

Jeff, shall I start to revive the push model? I think I have some backups

Stefan

Jeff McAffer wrote:

Thanks for all the comments and info Scott (and others).  First, this thread started with something completely unrelated to ECF.  I was just interested in whether the call to RequestHandler.download() happen in the MirrorRequest or somewhere in the ArtifactRepository (or elsewhere).  In the end I think that that has been resolved and the call will be moved as I restructure some of the code.

As for using ECF, I am all for using it and so far have not found it to be particularly limiting or limited.  If it were then I expect that we would work with you to understand how we should use it or to enhance it to suit the requirements.  For example, my recent questions about chaining InputStreams.  Given your advice I am going to revisit the approach I proposed and Stefan implemented to see if we can flip it around to use OutputStreams and have ECF *push* data through the pipe rather than having clients *pull* data out of the pipe.  Should be resaonbly straightforward as this is what Stefan had originally (sorry Stefan  Anyway, having said that, depending on how complex this gets, it may be worth our will to still maintain an insulating later between p2 and whatever handler technology we are using.  Your points about potential complexity here are well taken and that will have to weigh into the consideration.

There is a valid question of whether or not we expose handlers and ECF in the p2 API.  We would do well to avoid it if possible.  Not because there is anything wrong with ECF rather if we can implement p2 without exposing ECF then it is likely simpler as there would likely be less API and fewer concepts.  Of course, that might come at the expense of flexibility...  We will have to see.

Finally, we will certainly take you up on your offer of assistance in structuring the handler code and other bits.   Thanks

Jeff
 

Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org> Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org 08/31/2007 09:20 PM Please respond to Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> cc Subject Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

I admit I'm a little confused by this thread, as it seems bring up a
range of issues...some of which are related to ECF functionality and
some of which don't seem (to me) to be directly related to ECF per se
(but rather the provisioning request handlers?).

RE: Stefan's original comments about the ECF proxy handling and
authentication structure...the API supports both proxy and arbitrary
auth mechanisms for whatever protocol/provider implementation is used
for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF
exposes extension points for adding support for other protocols (e.g.
private ones like a repository-specific protocol).

RE: defining request handlers externally...I think the current version
of ECFHandler (version I looked at few weeks ago anyway) is overly tied
to a *particular* (default) protocol/provider (http via URLConnection).  
I think this handler could be abstracted and made pluggable, but I
haven't yet given much thought to how this would be done as I'm not yet
familiar enough with all the provisioning code to understand the
external API requirements on request handlers.

Pascal Rapicault wrote:
> In scenarios where size matters, or where only one well-known transport is
> to be used, the handler give us the ability to remove our dependency on
> ECF.
> So to me, to know whether or not the handler should be kept, we have to
> answer the following questions:
>
> * Size
> - Is ECF small enough for scenarios where size matters?
>  

What would be considered 'small enough'?  I know zero bytes of code is
best :), but that seems a little 'severe'.  Of course ECF's pluggable
transport nature could be sacrificed and a return to the JRE-provided
URLConnection could be used instead, but this returns things to the
state prior to the equinox provisioning work (i.e. bound to a specific
transport...e.g. http).

I guess I'm not clear on what benefit removing the dependency on ECF
would have other than a fairly small change in code size, and it's costs
(return to lack of flexibility in transports) would be pretty clear.  
Besides, what's the problem?

> - Can the removal of the dependency on ECF be achieved by another way (for
> example having a new DownloadManager)?
>
> * Pluggability
> - Can any transport be plugged into ECF, if not what is missing from the
> API?
>  

This is a very important question.  I would assert than any file
transfer protocol of interest can be plugged into the ECF filetransfer
API...but if this turns out to be wrong for some transport and API
changes (as opposed to additions) are needed, then I would like to know
about that as soon as possible.

> - How more complex would the handler have to become, which other
> infrastructure would we have to have when ECF is not present (e.g. how do
> we know which transports are supported)?
>  

I would guess that the handler would have to become significantly more
complex without ECF, because if multiple/pluggable transports are
desired/required then *some* abstraction has to be introduced to provide
pluggability/flexibility at the transport level.  ECF is essentially
that abstraction.

> - How complex is it to plug a new transport?
>
> * Functionality
> - What does ECF brings us?
>  
I would offer that it provides a consistent API to get pluggable file
transfer protocols, suspendable/resumeable transfers, and other goals
for transport pluggability as described here

http://wiki.eclipse.org/Equinox_Provisioning_Plan

...and probably other places.

> - Will ECF be able to overcome its current limitations? Is the ECF team
> aware of these?
>  
RE: the current (implementation) limitations WRT proxy handling...we have:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286

Beyond these, I'm not exactly clear on what people are suggesting are
the limitations of ECF API or specific protocol implementations.  If
there are specific limitations (outside the proxy issues) that I/we
should know about then I would appreciate bug and/or enhancement
requests.  We are completely able and willing to address any such
limitations as they are identified.

> Can any one take a look at this?
>  

By take a look at this do you mean looking at
redesigning/reimplementing/generalizing the provisioning request handler
(ECFHandler as current impl) structure or something else?  In either
case, I can probably contribute if that's desired.  But I would like to
understand better what the current deficiencies are (beyond full impl
support for proxy handling).

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________ equinox-dev mailing list equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [prov] ECF in P2, was request handler orientation

Scott, can ECF detect the internet proxy settings from the operating 
system/browser, e.g. on win32 by using the native WinHTTP library?

Stefan

Scott Lewis wrote:
> I admit I'm a little confused by this thread, as it seems bring up a 
> range of issues...some of which are related to ECF functionality and 
> some of which don't seem (to me) to be directly related to ECF per se 
> (but rather the provisioning request handlers?).
>
> RE: Stefan's original comments about the ECF proxy handling and 
> authentication structure...the API supports both proxy and arbitrary 
> auth mechanisms for whatever protocol/provider implementation is used 
> for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF 
> exposes extension points for adding support for other protocols (e.g. 
> private ones like a repository-specific protocol).
>
> RE: defining request handlers externally...I think the current version 
> of ECFHandler (version I looked at few weeks ago anyway) is overly 
> tied to a *particular* (default) protocol/provider (http via 
> URLConnection).  I think this handler could be abstracted and made 
> pluggable, but I haven't yet given much thought to how this would be 
> done as I'm not yet familiar enough with all the provisioning code to 
> understand the external API requirements on request handlers.
>
> Pascal Rapicault wrote:
>> In scenarios where size matters, or where only one well-known 
>> transport is
>> to be used, the handler give us the ability to remove our dependency on
>> ECF.
>> So to me, to know whether or not the handler should be kept, we have to
>> answer the following questions:
>>
>> * Size
>> - Is ECF small enough for scenarios where size matters?
>>   
>
> What would be considered 'small enough'?  I know zero bytes of code is 
> best :), but that seems a little 'severe'.  Of course ECF's pluggable 
> transport nature could be sacrificed and a return to the JRE-provided 
> URLConnection could be used instead, but this returns things to the 
> state prior to the equinox provisioning work (i.e. bound to a specific 
> transport...e.g. http).
>
> I guess I'm not clear on what benefit removing the dependency on ECF 
> would have other than a fairly small change in code size, and it's 
> costs (return to lack of flexibility in transports) would be pretty 
> clear.  Besides, what's the problem?
>
>> - Can the removal of the dependency on ECF be achieved by another way 
>> (for
>> example having a new DownloadManager)?
>>
>> * Pluggability
>> - Can any transport be plugged into ECF, if not what is missing from the
>> API?
>>   
>
> This is a very important question.  I would assert than any file 
> transfer protocol of interest can be plugged into the ECF filetransfer 
> API...but if this turns out to be wrong for some transport and API 
> changes (as opposed to additions) are needed, then I would like to 
> know about that as soon as possible.
>
>> - How more complex would the handler have to become, which other
>> infrastructure would we have to have when ECF is not present (e.g. 
>> how do
>> we know which transports are supported)?
>>   
>
> I would guess that the handler would have to become significantly more 
> complex without ECF, because if multiple/pluggable transports are 
> desired/required then *some* abstraction has to be introduced to 
> provide pluggability/flexibility at the transport level.  ECF is 
> essentially that abstraction.
>
>> - How complex is it to plug a new transport?
>>
>> * Functionality
>> - What does ECF brings us?
>>   
> I would offer that it provides a consistent API to get pluggable file 
> transfer protocols, suspendable/resumeable transfers, and other goals 
> for transport pluggability as described here
>
> http://wiki.eclipse.org/Equinox_Provisioning_Plan
>
> ...and probably other places.
>
>> - Will ECF be able to overcome its current limitations? Is the ECF team
>> aware of these?
>>   
> RE: the current (implementation) limitations WRT proxy handling...we 
> have:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286
>
> Beyond these, I'm not exactly clear on what people are suggesting are 
> the limitations of ECF API or specific protocol implementations.  If 
> there are specific limitations (outside the proxy issues) that I/we 
> should know about then I would appreciate bug and/or enhancement 
> requests.  We are completely able and willing to address any such 
> limitations as they are identified.
>
>> Can any one take a look at this?
>>   
>
> By take a look at this do you mean looking at 
> redesigning/reimplementing/generalizing the provisioning request 
> handler (ECFHandler as current impl) structure or something else?  In 
> either case, I can probably contribute if that's desired.  But I would 
> like to understand better what the current deficiencies are (beyond 
> full impl support for proxy handling).
>
> Scott
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [prov] ECF in P2, was request handler orientation

Hi Stefan,

Stefan Liebig wrote:
> Scott, can ECF detect the internet proxy settings from the operating 
> system/browser, e.g. on win32 by using the native WinHTTP library?

The current file transfer providers don't, but a new/extended provider 
could do this.

But wouldn't it be more effective to use the Eclipse platform proxy 
settings:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=154100

We already have a bug to support this 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544

Scott

>
> Stefan
>
> Scott Lewis wrote:
>> I admit I'm a little confused by this thread, as it seems bring up a 
>> range of issues...some of which are related to ECF functionality and 
>> some of which don't seem (to me) to be directly related to ECF per se 
>> (but rather the provisioning request handlers?).
>>
>> RE: Stefan's original comments about the ECF proxy handling and 
>> authentication structure...the API supports both proxy and arbitrary 
>> auth mechanisms for whatever protocol/provider implementation is used 
>> for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF 
>> exposes extension points for adding support for other protocols (e.g. 
>> private ones like a repository-specific protocol).
>>
>> RE: defining request handlers externally...I think the current 
>> version of ECFHandler (version I looked at few weeks ago anyway) is 
>> overly tied to a *particular* (default) protocol/provider (http via 
>> URLConnection).  I think this handler could be abstracted and made 
>> pluggable, but I haven't yet given much thought to how this would be 
>> done as I'm not yet familiar enough with all the provisioning code to 
>> understand the external API requirements on request handlers.
>>
>> Pascal Rapicault wrote:
>>> In scenarios where size matters, or where only one well-known 
>>> transport is
>>> to be used, the handler give us the ability to remove our dependency on
>>> ECF.
>>> So to me, to know whether or not the handler should be kept, we have to
>>> answer the following questions:
>>>
>>> * Size
>>> - Is ECF small enough for scenarios where size matters?
>>>   
>>
>> What would be considered 'small enough'?  I know zero bytes of code 
>> is best :), but that seems a little 'severe'.  Of course ECF's 
>> pluggable transport nature could be sacrificed and a return to the 
>> JRE-provided URLConnection could be used instead, but this returns 
>> things to the state prior to the equinox provisioning work (i.e. 
>> bound to a specific transport...e.g. http).
>>
>> I guess I'm not clear on what benefit removing the dependency on ECF 
>> would have other than a fairly small change in code size, and it's 
>> costs (return to lack of flexibility in transports) would be pretty 
>> clear.  Besides, what's the problem?
>>
>>> - Can the removal of the dependency on ECF be achieved by another 
>>> way (for
>>> example having a new DownloadManager)?
>>>
>>> * Pluggability
>>> - Can any transport be plugged into ECF, if not what is missing from 
>>> the
>>> API?
>>>   
>>
>> This is a very important question.  I would assert than any file 
>> transfer protocol of interest can be plugged into the ECF 
>> filetransfer API...but if this turns out to be wrong for some 
>> transport and API changes (as opposed to additions) are needed, then 
>> I would like to know about that as soon as possible.
>>
>>> - How more complex would the handler have to become, which other
>>> infrastructure would we have to have when ECF is not present (e.g. 
>>> how do
>>> we know which transports are supported)?
>>>   
>>
>> I would guess that the handler would have to become significantly 
>> more complex without ECF, because if multiple/pluggable transports 
>> are desired/required then *some* abstraction has to be introduced to 
>> provide pluggability/flexibility at the transport level.  ECF is 
>> essentially that abstraction.
>>
>>> - How complex is it to plug a new transport?
>>>
>>> * Functionality
>>> - What does ECF brings us?
>>>   
>> I would offer that it provides a consistent API to get pluggable file 
>> transfer protocols, suspendable/resumeable transfers, and other goals 
>> for transport pluggability as described here
>>
>> http://wiki.eclipse.org/Equinox_Provisioning_Plan
>>
>> ...and probably other places.
>>
>>> - Will ECF be able to overcome its current limitations? Is the ECF team
>>> aware of these?
>>>   
>> RE: the current (implementation) limitations WRT proxy handling...we 
>> have:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286
>>
>> Beyond these, I'm not exactly clear on what people are suggesting are 
>> the limitations of ECF API or specific protocol implementations.  If 
>> there are specific limitations (outside the proxy issues) that I/we 
>> should know about then I would appreciate bug and/or enhancement 
>> requests.  We are completely able and willing to address any such 
>> limitations as they are identified.
>>
>>> Can any one take a look at this?
>>>   
>>
>> By take a look at this do you mean looking at 
>> redesigning/reimplementing/generalizing the provisioning request 
>> handler (ECFHandler as current impl) structure or something else?  In 
>> either case, I can probably contribute if that's desired.  But I 
>> would like to understand better what the current deficiencies are 
>> (beyond full impl support for proxy handling).
>>
>> Scott
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@...
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [prov] ECF in P2, was request handler orientation

Yes, that is exactly what I am looking for. Thanks!

Stefan

Scott Lewis wrote:
> Hi Stefan,
>
> Stefan Liebig wrote:
>> Scott, can ECF detect the internet proxy settings from the operating 
>> system/browser, e.g. on win32 by using the native WinHTTP library?
>
> The current file transfer providers don't, but a new/extended provider 
> could do this.
>
> But wouldn't it be more effective to use the Eclipse platform proxy 
> settings:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=154100
>
> We already have a bug to support this 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
>
> Scott
>
>>
>> Stefan
>>
>> Scott Lewis wrote:
>>> I admit I'm a little confused by this thread, as it seems bring up a 
>>> range of issues...some of which are related to ECF functionality and 
>>> some of which don't seem (to me) to be directly related to ECF per 
>>> se (but rather the provisioning request handlers?).
>>>
>>> RE: Stefan's original comments about the ECF proxy handling and 
>>> authentication structure...the API supports both proxy and arbitrary 
>>> auth mechanisms for whatever protocol/provider implementation is 
>>> used for the underlying file transfer 
>>> (http/ftp/efs/bittorrent/etc).  ECF exposes extension points for 
>>> adding support for other protocols (e.g. private ones like a 
>>> repository-specific protocol).
>>>
>>> RE: defining request handlers externally...I think the current 
>>> version of ECFHandler (version I looked at few weeks ago anyway) is 
>>> overly tied to a *particular* (default) protocol/provider (http via 
>>> URLConnection).  I think this handler could be abstracted and made 
>>> pluggable, but I haven't yet given much thought to how this would be 
>>> done as I'm not yet familiar enough with all the provisioning code 
>>> to understand the external API requirements on request handlers.
>>>
>>> Pascal Rapicault wrote:
>>>> In scenarios where size matters, or where only one well-known 
>>>> transport is
>>>> to be used, the handler give us the ability to remove our 
>>>> dependency on
>>>> ECF.
>>>> So to me, to know whether or not the handler should be kept, we 
>>>> have to
>>>> answer the following questions:
>>>>
>>>> * Size
>>>> - Is ECF small enough for scenarios where size matters?
>>>>   
>>>
>>> What would be considered 'small enough'?  I know zero bytes of code 
>>> is best :), but that seems a little 'severe'.  Of course ECF's 
>>> pluggable transport nature could be sacrificed and a return to the 
>>> JRE-provided URLConnection could be used instead, but this returns 
>>> things to the state prior to the equinox provisioning work (i.e. 
>>> bound to a specific transport...e.g. http).
>>>
>>> I guess I'm not clear on what benefit removing the dependency on ECF 
>>> would have other than a fairly small change in code size, and it's 
>>> costs (return to lack of flexibility in transports) would be pretty 
>>> clear.  Besides, what's the problem?
>>>
>>>> - Can the removal of the dependency on ECF be achieved by another 
>>>> way (for
>>>> example having a new DownloadManager)?
>>>>
>>>> * Pluggability
>>>> - Can any transport be plugged into ECF, if not what is missing 
>>>> from the
>>>> API?
>>>>   
>>>
>>> This is a very important question.  I would assert than any file 
>>> transfer protocol of interest can be plugged into the ECF 
>>> filetransfer API...but if this turns out to be wrong for some 
>>> transport and API changes (as opposed to additions) are needed, then 
>>> I would like to know about that as soon as possible.
>>>
>>>> - How more complex would the handler have to become, which other
>>>> infrastructure would we have to have when ECF is not present (e.g. 
>>>> how do
>>>> we know which transports are supported)?
>>>>   
>>>
>>> I would guess that the handler would have to become significantly 
>>> more complex without ECF, because if multiple/pluggable transports 
>>> are desired/required then *some* abstraction has to be introduced to 
>>> provide pluggability/flexibility at the transport level.  ECF is 
>>> essentially that abstraction.
>>>
>>>> - How complex is it to plug a new transport?
>>>>
>>>> * Functionality
>>>> - What does ECF brings us?
>>>>   
>>> I would offer that it provides a consistent API to get pluggable 
>>> file transfer protocols, suspendable/resumeable transfers, and other 
>>> goals for transport pluggability as described here
>>>
>>> http://wiki.eclipse.org/Equinox_Provisioning_Plan
>>>
>>> ...and probably other places.
>>>
>>>> - Will ECF be able to overcome its current limitations? Is the ECF 
>>>> team
>>>> aware of these?
>>>>   
>>> RE: the current (implementation) limitations WRT proxy handling...we 
>>> have:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286
>>>
>>> Beyond these, I'm not exactly clear on what people are suggesting 
>>> are the limitations of ECF API or specific protocol 
>>> implementations.  If there are specific limitations (outside the 
>>> proxy issues) that I/we should know about then I would appreciate 
>>> bug and/or enhancement requests.  We are completely able and willing 
>>> to address any such limitations as they are identified.
>>>
>>>> Can any one take a look at this?
>>>>   
>>>
>>> By take a look at this do you mean looking at 
>>> redesigning/reimplementing/generalizing the provisioning request 
>>> handler (ECFHandler as current impl) structure or something else?  
>>> In either case, I can probably contribute if that's desired.  But I 
>>> would like to understand better what the current deficiencies are 
>>> (beyond full impl support for proxy handling).
>>>
>>> Scott
>>>
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@...
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [prov] ECF in P2, was request handler orientation

 Thanks.  I think I will flip it around without piped streams since the handler already forks jobs etc.  Feel free to pick apart the upcoming proposal.

Jeff

Stefan Liebig <Stefan.Liebig-cVb/9OIi+YmoYr4blSSd5g@public.gmane.org> Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org 09/01/2007 11:11 AM Please respond to Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> cc Subject Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

Jeff, shall I start to revive the push model? I think I have some backups

Stefan

Jeff McAffer wrote:

Thanks for all the comments and info Scott (and others).  First, this thread started with something completely unrelated to ECF.  I was just interested in whether the call to RequestHandler.download() happen in the MirrorRequest or somewhere in the ArtifactRepository (or elsewhere).  In the end I think that that has been resolved and the call will be moved as I restructure some of the code.

As for using ECF, I am all for using it and so far have not found it to be particularly limiting or limited.  If it were then I expect that we would work with you to understand how we should use it or to enhance it to suit the requirements.  For example, my recent questions about chaining InputStreams.  Given your advice I am going to revisit the approach I proposed and Stefan implemented to see if we can flip it around to use OutputStreams and have ECF *push* data through the pipe rather than having clients *pull* data out of the pipe.  Should be resaonbly straightforward as this is what Stefan had originally (sorry Stefan  Anyway, having said that, depending on how complex this gets, it may be worth our will to still maintain an insulating later between p2 and whatever handler technology we are using.  Your points about potential complexity here are well taken and that will have to weigh into the consideration.

There is a valid question of whether or not we expose handlers and ECF in the p2 API.  We would do well to avoid it if possible.  Not because there is anything wrong with ECF rather if we can implement p2 without exposing ECF then it is likely simpler as there would likely be less API and fewer concepts.  Of course, that might come at the expense of flexibility...  We will have to see.

Finally, we will certainly take you up on your offer of assistance in structuring the handler code and other bits.   Thanks

Jeff
 

Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org> Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org 08/31/2007 09:20 PM Please respond to Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> cc Subject Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

I admit I'm a little confused by this thread, as it seems bring up a
range of issues...some of which are related to ECF functionality and
some of which don't seem (to me) to be directly related to ECF per se
(but rather the provisioning request handlers?).

RE: Stefan's original comments about the ECF proxy handling and
authentication structure...the API supports both proxy and arbitrary
auth mechanisms for whatever protocol/provider implementation is used
for the underlying file transfer (http/ftp/efs/bittorrent/etc).  ECF
exposes extension points for adding support for other protocols (e.g.
private ones like a repository-specific protocol).

RE: defining request handlers externally...I think the current version
of ECFHandler (version I looked at few weeks ago anyway) is overly tied
to a *particular* (default) protocol/provider (http via URLConnection).  
I think this handler could be abstracted and made pluggable, but I
haven't yet given much thought to how this would be done as I'm not yet
familiar enough with all the provisioning code to understand the
external API requirements on request handlers.

Pascal Rapicault wrote:
> In scenarios where size matters, or where only one well-known transport is
> to be used, the handler give us the ability to remove our dependency on
> ECF.
> So to me, to know whether or not the handler should be kept, we have to
> answer the following questions:
>
> * Size
> - Is ECF small enough for scenarios where size matters?
>  

What would be considered 'small enough'?  I know zero bytes of code is
best :), but that seems a little 'severe'.  Of course ECF's pluggable
transport nature could be sacrificed and a return to the JRE-provided
URLConnection could be used instead, but this returns things to the
state prior to the equinox provisioning work (i.e. bound to a specific
transport...e.g. http).

I guess I'm not clear on what benefit removing the dependency on ECF
would have other than a fairly small change in code size, and it's costs
(return to lack of flexibility in transports) would be pretty clear.  
Besides, what's the problem?

> - Can the removal of the dependency on ECF be achieved by another way (for
> example having a new DownloadManager)?
>
> * Pluggability
> - Can any transport be plugged into ECF, if not what is missing from the
> API?
>  

This is a very important question.  I would assert than any file
transfer protocol of interest can be plugged into the ECF filetransfer
API...but if this turns out to be wrong for some transport and API
changes (as opposed to additions) are needed, then I would like to know
about that as soon as possible.

> - How more complex would the handler have to become, which other
> infrastructure would we have to have when ECF is not present (e.g. how do
> we know which transports are supported)?
>  

I would guess that the handler would have to become significantly more
complex without ECF, because if multiple/pluggable transports are
desired/required then *some* abstraction has to be introduced to provide
pluggability/flexibility at the transport level.  ECF is essentially
that abstraction.

> - How complex is it to plug a new transport?
>
> * Functionality
> - What does ECF brings us?
>  
I would offer that it provides a consistent API to get pluggable file
transfer protocols, suspendable/resumeable transfers, and other goals
for transport pluggability as described here

http://wiki.eclipse.org/Equinox_Provisioning_Plan

...and probably other places.

> - Will ECF be able to overcome its current limitations? Is the ECF team
> aware of these?
>  
RE: the current (implementation) limitations WRT proxy handling...we have:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181544
https://bugs.eclipse.org/bugs/show_bug.cgi?id=192286

Beyond these, I'm not exactly clear on what people are suggesting are
the limitations of ECF API or specific protocol implementations.  If
there are specific limitations (outside the proxy issues) that I/we
should know about then I would appreciate bug and/or enhancement
requests.  We are completely able and willing to address any such
limitations as they are identified.

> Can any one take a look at this?
>  

By take a look at this do you mean looking at
redesigning/reimplementing/generalizing the provisioning request handler
(ECFHandler as current impl) structure or something else?  In either
case, I can probably contribute if that's desired.  But I would like to
understand better what the current deficiencies are (beyond full impl
support for proxy handling).

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 _______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[sec] Using JAAS framework: "Could not locate JAAS Configuration"

Hi all

I'm trying to use the JAAS framework of the Equinox Security project
(http://www.eclipse.org/equinox/incubator/security/) in another project.
I've successfully built and run the provided unit tests and the sample
program, but I fail when trying to use it in another bundle. It fails to
find the JAAS configuration:

03.09.2007 08:38:00
org.eclipse.equinox.internal.security.auth.ConfigurationFederator
getAppConfigurationEntry Could not locate JAAS Configuration with name
"", verify that the configuration exists and is non-empty
03.09.2007 08:38:00
org.eclipse.equinox.internal.security.auth.ConfigurationFederator
getAppConfigurationEntry Could not locate JAAS Configuration with name
"other", verify that the configuration exists and is non-empty
javax.security.auth.login.LoginException: No LoginModules configured for

The security properties are set in the start() method of the Activator:

Security.setProperty("login.configuration.provider",
"org.eclipse.equinox.security.boot.auth.ConfigurationProvider");
Security.setProperty("login.config.url.1", 

context.getBundle().getEntry("/data/jaas_config.xml").toExternalForm());

This should be ok because
System.out.println(Platform.resolve(context.getBundle().getEntry("/data/
jaas_config.xml")));
returns the correct full path to the configuration file.

What doesn't seem ok is that neither SecurePlatform nor the loginContext
return a ConfigurationName:
System.out.println(SecurePlatform.getConfigurationName());
System.out.println(SecurePlatform.getLoginContext().getConfigurationName
());
Both lines remain empty.

I'm sure I'm missing something obvious here. Debugging isn't helped by
the fact that I'm both an OSGi and a JAAS newbie. One difference to the
sample program is that I implement org.osgi.framework.BundleActivator
and not org.eclipse.core.runtime.IPlatformRunnable.

Any ideas are very much appreciated.

Thanks

Arthur

AW: [sec] Using JAAS framework: "Could not locate JAAS Configuration"

Hi again

Update: Looks like I'm having troubles getting the
org.eclipse.equinox.security.auth/loginConfigName property set. I do it the same way as in the
example via the ini-file reference in plugin.xml but it doesn't seem to get read. I've also failed setting
it at runtime so far.

Arthur

-----Ursprüngliche Nachricht-----
Von: Arthur van Dorp 
Gesendet: Montag, 3. September 2007 09:55
An: 'equinox-dev@...'
Betreff: [sec] Using JAAS framework: "Could not locate JAAS Configuration"

Hi all

I'm trying to use the JAAS framework of the Equinox Security project
(http://www.eclipse.org/equinox/incubator/security/) in another project. I've successfully
built and run the provided unit tests and the sample program, but I fail when trying to use it in another
bundle. It fails to find the JAAS configuration:

03.09.2007 08:38:00 org.eclipse.equinox.internal.security.auth.ConfigurationFederator
getAppConfigurationEntry Could not locate JAAS Configuration with name "", verify that the
configuration exists and is non-empty
03.09.2007 08:38:00 org.eclipse.equinox.internal.security.auth.ConfigurationFederator
getAppConfigurationEntry Could not locate JAAS Configuration with name "other", verify that the
configuration exists and is non-empty
javax.security.auth.login.LoginException: No LoginModules configured for 

The security properties are set in the start() method of the Activator:

Security.setProperty("login.configuration.provider", "org.eclipse.equinox.security.boot.auth.ConfigurationProvider");
Security.setProperty("login.config.url.1", 
  context.getBundle().getEntry("/data/jaas_config.xml").toExternalForm());						

This should be ok because
System.out.println(Platform.resolve(context.getBundle().getEntry("/data/jaas_config.xml")));
returns the correct full path to the configuration file.

What doesn't seem ok is that neither SecurePlatform nor the loginContext return a ConfigurationName:
System.out.println(SecurePlatform.getConfigurationName());
System.out.println(SecurePlatform.getLoginContext().getConfigurationName());
Both lines remain empty.

I'm sure I'm missing something obvious here. Debugging isn't helped by the fact that I'm both an OSGi and a
JAAS newbie. One difference to the sample program is that I implement
org.osgi.framework.BundleActivator and not org.eclipse.core.runtime.IPlatformRunnable.

Any ideas are very much appreciated.

Thanks

Arthur

Equinox projects tagged for 3.4 I-build