Progress and some thoughts

[M. David Peterson]

> I used the WebClient class mostly for convenience but (Http)WebRequest is
> really needed since it allows for a timeout and a redirection limit and a
> limit on the amount of data it's willing to receive.

Youre right, WebClient is nice but the proper approach is from the 
WebRequest standpoint given the nature of the design/purpose of a WebClient 
and the short term 'relationship' taking place which is less of a 
relationship and more of a simple service being provided.

> The C# version is more of a hybrid though :). I started it because I
> couldn't really get a decent trace with just PHP on both ends.

Have you looked at and/or installed Phalanger? Take a look at 
http://www.php-compiler.net and you may find just what the Dr. ordered if 
you are more of a PHP guy but want the power of the .NET platform enough to 
push your development more towards the ASP.NET <http://ASP.NET> style of 
coding. I have found a few projects that have proven a pain in the butt to 
try and implement (e.g. Drupal is one I have yet to get working via 
Phalanger , IIS, and ASP.NET <http://ASP.NET>) but there are enough BIG PHP 
projects out there that run without a hitch and I can verify the speed 
increase is absolutely spot on... it really does kick some serious standard 
PHP and PHP+Zen a$$.

Beyond this and moving forward from a complete C# ASP.NET
<http://ASP.NET>implementation standpoint... as I mentioned there are
several of us who have
expressed interest in such an implementation and have flirted with actually 
moving forward with it several times but have run into similar concerns in 
regards to what is the current and (more than likely or at least very close 
to) final specification for the first release. Up until this point I have 
been looking at the Perl server-side code base and I know there are several 
threads that have done a really good job of summing up the current state 
quite nicely. None-the-less the question is definitely worth bringing up 
again to ensure that what is developed is based on what these fine 
architects have been working over to perfection over the last few weeks (its 
been a fun process to watch although I must admit I havent been able to keep 
up all that well as of late and as such have definitely been left trying to 
make sense of things from the outside looking in and have definitely had a 
hard time nailing down exactly what needs to be implemented and the proper 
sequence of each process within each algorithm within the start to finish 
transaction of a properly implemented OpenID client/server transactional 
process.

To The Group: I hate to ask this question again but to ensure that we can 
simply just write the code and know that it is architecturely correct from 
the start can someone either point to the thread or possibly an up-to-date 
document or wiki entry that contains the hard core technical specification 
of OpenID from start to finish that is either non-language/platform specific 
(e.g. doesnt focus on the Perl modules necessary to implement a successful 
implementation) and instead each and every step of the process, the name and 
mandatory and/or optional parameters, and the expected return type and if 
necessary, the actual value of the type if practical/possible. You are all 
obviously aware of just how popular this project will become once a final 
release is made and word hits the streets. The potential of .NET installs is 
enormous and as such having a fully tested and fully functional 
implementation ready to go at the release will go a long ways in bringing in 
these developers to the OpenID way of thinking immediatelly.

I cant remember if I ever announced the location of the Subversion 
repository and Trac Project Management interface for the
OpenID.NET<http://OpenID.NET>project we technically started a few
weeks ago. In case they are not widely
known the Trac UI for this project is at:

> http://trac.x2x2x.org/projects/openid.net 

and the Subversion repository is located at:

> http://source.x2x2x.org/svn/OpenID.NET/ 

Nothing has been checked in as we haven't been able to determine (completely 
from our own lack of time to properly manage things) just what it is we need 
to develop. I do know that once we get that nailed down it will only be a 
matter of a few hours, if that, to get things developed enough such that the 
project can begin the testing phase. As such any and all help will most 
definitely be appreciated as I know quite a few projects who are anxious to 
take the implementation we create and put it into immediatte use.

Jason, do you have any thoughts/comments at the moment?

Thanks everyone!

<M:D/>

On 6/23/05, meepbear * <meepbear at hotmail.com> wrote: 
> 
> >Hi,
> >
> >You mentioned a C# version in your original post. Have you opened the 
> >source
> >for this portion of your implementation? Several of use have been hacking 
> a
> >C# implementation here and there but had then decided to hold off until
> >things had become a bit more finalized in regards to architecture. We 
> were 
> >going to spend some time this weekend but that didnt work out. If you 
> have
> >a
> >working C# implementation this would be wonderful!
> >
> >Any chance of gainging access to this source?
> The C# version is more of a hybrid though :). I started it because I 
> couldn't really get a decent trace with just PHP on both ends.
> It ended up having consumer/UA and server parts but in the current form 
> it's
> more of a UI protocol debugging aid then something to really plug in an 
> ASP.NET <http://ASP.NET> page as is.
> 
> My biggest concern though is that since I couldn't find a current spec
> consumer or server, I implemented both at the same time. I'd really like 
> to
> test it (or the PHP version for that matter) against something someone 
> else 
> wrote to make sure I didn't just write something that works but isn't
> actually compliant with anything else before handing it off to someone 
> else.
> 
> Also, there's a number of things I brushed over just because the protocol 
> is 
> still in flux ("Unhandled exception" is user friendly enough for me :) ) 
> and
> some things I did wrong in retrospect.
> I used the WebClient class mostly for convenience but (Http)WebRequest is
> really needed since it allows for a timeout and a redirection limit and a 
> limit on the amount of data it's willing to receive.
> 
> 
> 


-- 
M. David Peterson <aka:xmlhacker/>
http://www.xsltblog.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20050623/e69cd6b1/attachment.htm