Menu
▾
▴
dynapi-dev
|
From: Eytan H. <ey...@tr...> - 2001-02-19 10:09:16
|
Again me. Have you had enough yet ;-) Just wanted to explain the whole TCanvas and OOJS stuff. I'm not working against anyone here and specifically not against pascal. This is an opensource group and like someone recetly stated it's not you or me it's us. I am only doing all of this code by myself because you didn't want to do it without it being tested. My only concern is that the API is not stable enough no fast enought and not built well to support future browsers. I know you all want to get done with NN6 before but I think that this is the best time to do it. With all these new browsers around. I don't mind if we call it canvas or dynlayer or if it's my code or pascals. I want the best code there is that's all! I know that webos is overkill. What they did is designed an OS. What we are doing are page add-ons. I was thinking of somthing in the middle. How about thinking about DynApplications. You can have many running in one browser (or not). I think that that would be the best model. I also still think that we should completely seperate widgets from DynLayer. I think the work on DynAPI should be split in to two: * DynLayer Getting the DynLayer 100% compatible (or is much as we can) and then tweeking it to take up less memory clear the memory it uses and run faster. * Enviroment for DynLayer This should include a type of application object which manages memory, focus, key events. And widget libraries. We should have the group of basic widgets: Label, Panel(Form, or somthing like that), Button and the rest and then we should have packs of widgets that extened functionalitiy? Anyone agree? Anyone disagree(pascal)? 8an |
|
From: Jordi - I. - M. <jmi...@or...> - 2001-02-19 10:22:58
|
I was about to send this as a new thread but it suits here: Worst thing about an offline weekend is having to go throught 200 mails in monday ( on monday ? at monday ? preposition problems, help !!!). What I'm going to say has already been said in the past ( as many other discussions that come and go from time to time ) but, come to think of it, there are not that many different things to discuss ( support for X browser, performance, when is bug Y going to be fixed.... ). I remember one year ago we were concerned about performance and code structure. It was a long discussion but finally we agreed to keep the code as it was, make it work first and then work on the code. I know there are still things to solve, we've got NS6 bugs and Mac issues, but the recent performance/structure concerns make me think that maybe now it is the time. Don't get me wrong: I'm not for starting from scratch again. We've got very good crossbrowsing support ( not 100%, but as good as it gets ) and the API's interface is pretty stable. Users don't complain about how the API is used but about how it performs ( speed / size ). Besides, progress on browser X support can be made at the same time the structure is re-defined. However, this won't work if we start discussing what's a DynLayer and what does it do. Regardless of the structure we come up with, we final user will get DynLayers and DynDocuments and eventListeners. Same thing, different internal structure. Nobody will tolerate having to learn again how does this work. They'll get fed up. Instead, we have a user interface we want to reach ( same we've got now, a list of objects each having a list of methods and properties ) and we should foccuse on what do we place BELOW this structure. And do it both without rushing and without impatience. Just do it. I haven't said anything new but I had to say it anyway. I'll think of it myself: I've had to read the code these days. I used to look at it as crossbrowser code and so I only cared about it working. But now it does work and I'm starting to look at it as 'code' and I see so many things that could be improved. Is there any way to have a master plan document where people can contribute ideas and don't get lost as easily as they get in the mail lists ? ------- - "I've saying this for weeks / months !" -- I know. - "Oh no, not again !!! Not a new version" I know as well - "Why don't you support NS6 first ?" I'm afraid the code structure is already being stretched too much. I ought to find myself confortable doing my debugging and looking for bugs. Now there are too many places to look at and too many 'patchy' code around. When you've solved lots of browser issues by adding if (is.X) statements the code degrades. Now we have a solid browser-specific base ( the current code ) from were we can extract what we need to do and the issues we need to take into account. We can build new code that reads better, works better and faster and does the same, because now we now what needs to be done. One year ago we didn't. |
|
From: Raymond S. <dst...@or...> - 2001-02-19 20:41:38
|
One thing we need to do is define a "single" header for new ideas. This
thread is all over the place, and the "subject title" shifts at will. How
about "DynAPI3alpha"?
I also agree that split-development along the lines of finishing critical
issues with DynAPI2 and expanding browser support as much as "can be done"
should be followed. Also, how we co-distribute the functional API vs.
BetaAPI should be clearly detailed on the homepage.
But, all that being said. I think the first objective is to:
1) STOP! It's a bit premature to be debating the implementation when we
haven't even detailed the "plan and next-generation API objectives"; Mission
Statement.
then proceed with...
2) Expose and consolidate all ideas related to what we would like the next
generation of the API to be able to do. LabCoat, this would be a good time
to unveil your thoughts and learning's.
3) Discuss and agree upon "how" we would like "do" to be accomplished. API
structure and implementation. Maybe a tad UMLish in nature. So we can
"see" what we would like the API to look like before it's built.
a) Object/Method Discovery
b) API assembly/construction diagram (UMLish)
c) API extensions. I would assume we are going for a highly extensible
and scalable architecture.
4) Build the base alpha API.
a) Construct.
b) Abuse
c) Iterate
d) Evolve
First lets agree to agree to think about the next generation API. Wishes,
wants and desires. Leave all specifics "out" for now..., just discuss the
objectives of the API in broad brush strokes.
This isn't going to happen overnight, if we think it will and push for
"minor" shifts in the current paradigm will be right here again in a year
"debating grand software architecture".
So, to get the proverbial ball rolling. I think everyone should detail
their "ideas" in non-specific terms as to what API3 should be capable of
doing. How it might look from a structure standpoint. How will it be
extensible? Lets include the whole world of the web; client/server and
conduits between them.
Almost everything we need to "think" about is already in the API. But I
would certainly like to see a diagram of what the next generation API would
look like before a single "if,then,else" hits a sheet of paper.
Ray
|
|
From: Raymond S. <dst...@or...> - 2001-02-19 23:31:04
|
I have 117 posts in archives under "2nd Generation API". Tonight I will muddle through them all. Extract as much information as I can and present it as a "Discussion Review", hopefully sometime late tonight or tomorrow. Ray |
|
From: Stephan R. <SR...@la...> - 2001-02-19 12:32:09
|
I have to admit that I didn't read all the postings in the last days, so maybe I'm missing alot. Also, maybe I'm boring, but may I remind you for the discussion here in the list some 5 weeks ago about splitting the files in browser specific versions? Stephan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X