FreeLists / openbeosnetteam / [openbeosnetteam] Re: PPP homepage

[Philippe Houdoin <philippe.houdoin@xxxxxxx>]

Forwarded to ML, as it may interested all of us there too... 
 
> > It looks good enough to me.  
>  
> The first version looked much uglier. I changed it quickly after having sent 
> the mail to you. ;) 
 
LOL! 
  
> > Why not import them into our /current/docs/develop/net documentation?  
>  
> Would anybody read that? It is better to have it separate and accessible to 
> all people, not only those who download via CVS. 
 
Hum, I host /current/docs/develop/net documentation online too, and the team 
page offer a "read them online" link. 
Anyway, I'm wrong, because it's only for developer-oriented documentation. 
 
> > Oh, I'was thinking about another way to handle userland features required 
> by  
> > PPP stack, for authentification at least: launching an application thru  
> > load_image() call. Via arguments, it's even possible to make such 
> application  
> > the whole Dial Up preflet/deskbar host/monitor thing.  
>  
> I do not understand what you mean here. Calling load_image() from 
> kernel-land?  
 
Yep. 
 
> Is that possible for apps that link against libbe.so? What will 
> happen if that app crashes? Or is it possible to request the start of an app 
> from kernel-land, but let it run as a userland app logged-in under a 
specific 
> user? 
 
Multi-user issue aside, I bet load_image() always create a new team. So it 
can't be a kernel-land *team*, which is a special team that the kernel 
self-create. 
 
However, I never tried (yet!) to call load_image() from a driver or kernel 
module, but if it works as expected, it would be great. 
 
> > I really dislike a background process waiting, when the PPP stack knows 
> when  
> > an interaction with user is required and can start itself.  
>  
> This will not only be a PPP background process. It is actually a net_server. 
> We could use it for things like adding/removing DNS servers from resolv.conf 
> via a small API (PPP needs that, for example). 
 
But a regular userland app (GUI or not) can perfectly do to that. 
Even kernel drivers and modules can do files creation/modification/deletion, 
in fact. 
No need here for a daemon/permanent process waiting ad vitam eternam for 
something net-related to do...  
 
Or did I miss something? 
 
> > Note it's not incompatible with other features you plan for this preflet,  
> > which I really like the current look and feel, BTW!  
> > Nothing forbit this preflet being started by user and then start pooling 
or 
>  
> > monitoring thru a port PPP stats.  
>  
> Which features do I plan for the preflet? :) I only remember a settings 
> add-on for the modem driver (when it is finished) and finishing the 
> error-checking stuff (and some UI improvements). Is there something missing 
> that you would like to have? 
 
Well, displaying dial up interface(s) status and live statistics, like R5's 
"Dial Up Networking" preflet. Which is also the one behind the deskbar 
replicant... 
 
But it's not a mandatory design to follow. 
I just guess users are used to such small GUI in Windows... and BeOS R5.0.x. 
 
> The preflet will not be used for showing PPP stats. The PPPServer plug-in 
> will add a Deskbar replicant that shows the stats and allows to disconnect. 
 
Deskbar replicants can be host in any app, not only permanent/background ones. 
The Deskbar app (his BShelf powering the deskbar tray view) will reinstanciate 
the deskbar item from the binary file where the object come from, thanks to 
app signature. 
  
> If it is possible to make the kernel run a userland app as if the user had 
> executed it (i.e., app is logged-in as that user, too) then it would be 
> really cool. 
> I just do not understand how this can be done via load_addon(). It will just 
> load the app in kernel-land. But somehow the kernel can execute apps, of 
> course, so we should be able to use its functions...sounds interesting. I 
> will consider that. 
> Thank you for this suggestion. 
 
I should tried to call load_image() from a driver really soon now (tm). 
But, I agree, the multi-user support could be an issue in the future... 
Will see then. 
 
- Philippe